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ABSTRACT 



The Naval Postgraduate School is developing an vertical take-off and landing (VTOL) unmanned air 
vehicle (UAV) that can transition to horizontal flight, once airborne, in order to take advantage of the 
improvements in speed, range, and loiter time that horizontal, fixed-wing flight provides. This research 
investigates the design requirements of the central controlling device for that UAV, including the specific 
problems of defining the necessary h;irdw;tre components and developing software for executive control. 

First, hiirdware requirements needed to be determined. By exploring the general operational 
requirements of the UAV and taking into account space and weight limitations, a hardware suite was selected 
which could provide adequate functionality to replace the human traits of a pilot. In order to provide 
“awareness” of the operational environment, motion sensors, navigation equipment, and communication 
equipment w;ts required. Controllable servo motors were necessary to move control surfaces appropriately. 
Computer hardware, necessttry to provide system intelligence, was selected in order to interoperate with the 
other hardw;ire. Next, a Real-Time Executive (RTE) software program was designed to provide the 
functionality and coordination of till hardware components. Device drivers for each component were 
developed, and overall coordination was planned using a Yourdon style essential model. Periodic interrupts 
were used to control execution time. Last, the specifications and configuration of all hardware components 
were completely documented, and the operation of the RTE program is fully explained. From this 
understanding of the ovemll control system, future development can continue, resulting in a more effective 
and efficient UAV design. 
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I. INTRODUCTION 



Control is defined as “the right or prerogative of determining or governing" [Ste73]. The control of any 
moving entity requires a correct determination of the current state of that entity followed by the careful 
governing of actions taken to correct any deviation from a given desired state. In an aircraft, this function is 
usually done by a human being. When removing the pilot from the aircraft, this control falls to a coordinated 
system of hmdware mid software called a controller. This controller must be built around some source of 
intelligence, whether it is remotely linked to a human, or intelligent in its own right. In addition, the controller 
must have the capability to create mid govern the necessary changes in the aircraft’s state. Since the 
controller’s roles are so varied and yet interrelated, there are many design options to consider -- the 
permutations of which comprise many possible, workable solutions. 

A. RESEARCH OBJECTIVE 

This research examines the design mid synthesis of a controller for an unmanned air vehicle (UAV). 
The primary research question is “What is required to build a central controller for an UAV?" A central 
controller is differentiated from any other auxiliary controllers that may be on board in that the central 
controller governs the actual flight control of the aircraft. This primary research question encompasses both 
hmdware and software requirements, and leads to additional questions: 

• What sensors will be used to provide information about the state of the aircraft, in the absence 
of human senses? 

• What is the form and limitations of the data provided by these sensors? 

• What aerodynamic surfaces tire available to control the aircraft? 

• What devices tire available to move the control surfaces, and what signals are required to cause 
these devices to move those surfaces? 

• How must the movement of these control surfaces be coordinated to control the aircraft in its 
six degrees of freedom? 

• Does the UAV need to eommunicate with any external facilities? 

• If the UAV does need to communicate with external facilities, how should this be 
accomplished? 

• What me the format mid buffering requirements for this communication link? 

• What other input and output (I/O) of data is required? 

• What me the liming constraints for all command, control, and communication operations? 

• What hardware is necessary to achieve this functionality? 

• What me the softwme requirements to interact with the chosen hmdware? 

With these questions in mind, the pmameters of operation and the system requirements for a UAV controller 
me investigated. The specifications mid configuration of the hardware and software used me fully 
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documented. The goal of this research project is a functional UAV controller, including a comprehensive 
Real-Time Executive software program fully integrated with the necessary hardware. 

B. PREVIOUS AND CONCURRENT RESEARCH 

Some of these questions have already been answered. This multi-faceted project is being developed in 
several previous ;ind concurrent research programs, bringing together disciplines from Aeronautical 
Engineering; Mechanical Engineering; Electrical Engineering; Command, Control and Communications; and 
Computer Science. The airframe was aerodynamically analyzed and modified by Stoney [Sto93]. Significant 
to this research was the addition of a canard on the front of the aircraft, which included two additional control 
surfaces. The servo motors used to move these and other control surfaces were examined by Merz [Mer92] 
and Moran [Mor93]. They developed a core control system for the aerodynamic control vanes. Two 
datalinks have been developed to facilitate the transfer of data to and from a ground station. Reichert [Rei93] 
designed a wide-band UHF system and Bess [Bes94] tested a spread spectrum datalink. For navigation. 
Twite [Twi94] developed a differential GPS navigation system, and Hallberg [Hal94] investigated the inertial 
measurement unit (IMU) which was used. Marquis [Mar93] designed a complementary Kalman filter to 
blend the outputs of these two sensors, and the control algorithm has been worked on by Davis [Dav92], 
Kuchenmeister [Kue93], Hallberg [Hal94], and Moats [Moa94]. 

C. EXECUTIVE SUMMARY 

This document consists of five chapters, including this Introduction. Chapter II provides a generic 
overview of the controller, discusses required functionality, and develops an essential model of this 
functionality in order to better understand the constraints and criteria under which it must operate. Chapter 
111 fully documents the specifications and configuration of all hardware used for the controller. It is intended 
to provide information in sufficient detail such that anew user would understand how to duplicate the existing 
hardware system upon receipt using similar equipment. Chapter IV fully documents the RTE software 
written for this project. This includes compiler information to enable a new user to recreate the software 
development environment under which the software was created. Chapter V delineates the conclusions 
drawn from this research ;ind provides recommendations for future improvements to the system. Appendix 
A contains a listing of the source code for the RTE. Appendix B contains a glossary listing of all variables 
used in the RTE program. Finally, Appendix C contains the manufacturer's technical data sheets for the 
hardwme used lor the controller. 
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This research project will tie together the many individual sub-systems that have been designed for the 
UAV and provide the ine;tns for their operational use and coordination. Additionally, this research stands as 
proof -of-concept for UAV technology, especially for vertical take-off and landing (VTOL) aircraft that can 
transition to horizontal flight. This characteristic makes it especially useful for shipboard deployment, which 
will benefit not only the Department of Defense, but also the U.S. Coast Guard by providing a cost-effective 
and fatigue-resistant solution to many airborne missions, such as Search and Rescue and Law Enforcement. 
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II. BACKGROUND 



This chapter provides background information detailing the objectives introduced in the last chapter. 
In this chapter, a generic overview of a controller is provided, design considerations are discussed, and a 
Yourdon style essential mode! [You89] is developed. Within this model, parameters and priorities unique to 
this system are investigated. Since it is a real-time system, timing and intra-process communications are 
determined. This analysis results in a more effective and efficient controller design. 

A. SYSTEM OVERVIEW 

In order to control the aircraft, a controller must have access to all information pertaining to the 
operation of the airframe, including: 

• Present and desired geographic position 

• Present and desired altitude 

• Present and desired airframe attitude (in 3 dimensions) 

• Present airframe acceleration (in 3 dimensions) 

• Present state of power plant, including throttle and fuel state 

• Present state of payload equipment mid desired operation of such equipment 

Then, a controller must be able to properly manipulate this information, develop signals to modify the 
physiad configuration of the aircraft’s control surfaces, and effect necessary data communications. To 
accomplish these results, a controller must maintain control over the following: 

• Signals that control each of the aircraft’s control surfaces 

• Signals that control the power plant (throttle) 

• Signals that control the payload equipment 

• Communication channels with ground control and/or monitoring stations 

In a digital controller, these signals m e processed by a set of software algorithms, interacting with specialized 
hardwttre. This set of algorithms comprises a Real-Time Executive program; the hardware includes sensors, 
servos, and communication equipment. As detailed by Moran [Mor93] and in Chapter III, the Archytas 
airframe uses the following components to meet these requirements: 

1. Aircraft Sensors 

The UAV needs speekdly designed sensors which can generate signals in response to position, 
posture and acceleration of the aircraft. Among the sensors with which the processor must interact are: 

• Global Position System (GPS) Satellite Receiver 

• Inertial Navigation System (INS) Instruments 

• Other (Non-INS) Flight Instruments 

• Fuel Sensor 
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The GPS receiver yields a time sUunp and a 3-dimensional position, including latitude, longitude, and 
altitude. The INS instruments include accelerometers that measure linear acceleration in each of the three 
dimensions, roll-rate sensors that measure angular velocity about each of the three coordinate axes, gyros that 
indicate aircraft heading, and vertical inclinometers that measure the angle of tilt from vertical. Non-INS 
instruments include a pitot tube airspeed indicator and a barometric altimeter. These sensors are “strapped 
down” which means they tire fixed in alignment with the body coordinate system , the 3-dimensional 
coordinate system that uses the body of the aircraft as a reference. They detect acceleration, velocity or 
displacement in a certain direction, in reference to the aircraft itself. To be useful, these signals must be 
converted to the coordinate system of the environment surrounding the aircraft, called the inertial coordinate 
system . This conversion involves only a basic matrix rotation, but can demand significant processing time. 

2. Aircraft Components 

In addition to the sensors, the controller has several extrinsic components with which the 
processor must interact. These include: 

• Pulse-Width Modulated Servos 

• Communications Link 

• Payload Equipment 

The servos ;ire electric motors that position aircraft controls as determined by the length of a received square 
pulse. The communication link is usually a radio datalink transmitting digital data. It provides two-way 
communication with the UAV, uplinking control information (commands) from the ground control station, 
and downlinking flight instrument data to a ground monitoring station. Payload equipment includes cameras, 
nukir, and other sensors not necessary for flight control, but used to complete the assigned mission. 

3. System Block Diagram 

The components mid sensors are merged together to form an integrated flight control system, as 
shown in Figure 11-1. The most basic UAV controller must be able to perform the following functionality: 

• Receive digital sensor inputs 

• Perform analog to digital conversion of all analog sensor inputs 

• Provide digital filtering for sensor data 

• Accept and process joystick and/or waypoint pilot commands from the uplink 

• Using input above, calculate control functions and determine control surface positions. 

• Generate appropriate command pulses and transmit them to servos. 

• Relay necesszuy posture and navigation information to ground through downlink 
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The sof tware components of this system sire the Kalman filter and the control algorithms. The Kalman filter 
is ;in algorithm that smooths the sensor data to provide the most reliable source of data input, based on the 
varying accuracy of given sensors over different periods of time. The control algorithms are based on 
aerodynamic properties specific to the UAV. These algorithms compare the posture and position of the 
aircraft to the desired posture and position, and determine what corrective actions must be taken. These 
software functions, in addition to the transfer of till data and signals coming from or going to the central 
processor (shown as arrows to and from the shaded tirea in Figure II-l), comprise the Real-Time Executive - 
- the software component of the controller. 




Figure II-l: System Block Diagram 
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4. Assumptions 

Since this project is based on the work of several students working concurrently, the scope of the 
controller’s functionality for this research is limited by several assumptions. All of these assumptions can be 
subsutntiated once the controller is fully completed and tested on the aircraft in flight. 

a . F iltering and control algorithms exist as system callable subroutines . 

The filtering and control algorithms are specialized aeronautical engineering routines which 
involve additional research, such as linear quadratic filter design and wind tunnel testing, which is being 
accomplished by other students. For this project, it is assumed that the resulting routines will exist and can 
execute within die tdlotted time constraints. 

b . Input and output (HO) will not require central processing resources . 

Digital I/O will lake place through eight 25-pin RS-232 serial ports. These ports reside on a 
sepiirate circuit board that hits its own small processor. Although I/O must be initiated by a subroutine call 
from the main controller program, the processing required to execute and control the data flow is handled by 
this sub-processor and so will not require central processing resources. This form of parallel processing 
greatly reduces the amount of processing time required for this function. 

c. Air to ground communications will not require central processing resources. 

The radio data link hardware on hand conducts its own handshaking, parity checking, and 
other data communication functions. Since it will connect to the I/O ports, this function is actually twice 
removed from the controller itself. Even with an assumed 15% protocol overhead, the datalink is expected 
to have sufficient throughput to avoid becoming a bottleneck in the communication process, without 
requiring central processing resources. 

d. The sensors' data stream will be fast enough to provide fresh data for every cycle . 

It is imperative that the digital data from the Inertial Measurement Unit (IMU) is current and 
complete every control cycle. Additionally, sensor data which is not digital must first be converted from 
analog to digital (A/D) through a sampling A/D circuit board. This A/D process is done in hardware and will 
not tiffed the performance of the controller. However, if this A/D process takes too long, the most recent data 
from the A/D etird may not yet be available when read by the controller. It is assumed that current and 
complete sensor data will he available when needed for each control cycle. 
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e. The controller's processing speed will be sufficiently fast to perform all functions . 

No matter how last a processor is, it has a limited throughput. It is assumed that the CPU can 
perform ;dl required functions in the allotted real-time interval. If this assumption proves false, the present 
processing speed of 33 MHz will have to be upgraded. 

B. DESIGN CONSIDERATIONS 

In the design of a real-time system, it is important to understand the constraints, structures, and 
parameters of the system, as well as other design choices that are available to the designer. It is the 
combination of these design choices that determines the successfulness of the resulting system. This section 
dentils the constraints imposed by a real-time system, lists options for programming structure, and discusses 
considerations for the selection of a programming language and fault tolerance measures. 

1. Real-Time System Constraints 

The term real-time covers a wide range of systems; however, all systems share a common feature 
where results of some kind lire demanded by timing deadlines imposed by the environment outside the system 
[Sav85], As time inarches relentlessly onw;ird, all system and subsystem responses must fit within their 
allotted time fnunes. A real-time system can ;dso be described as reactive or embedded. Reactive systems 
iire those which have some ongoing interaction with their environment. Embedded systems are those used to 
control speckilized hardware in which the computer system is installed. Since the UAV controller will 
continuously monitor and interact with the position and posture of the aircraft within its environment and will 
also simultaneously control specialized hardware, it is both a reactive and an embedded system. 

It can be argued that ;dl practiced systems are real-time systems. Even a word-processing system 
must respond to user comimuids within a reasonable amount of time (e.g. 1 second), or it will become torture 
to use. Most literature refers to such systems as soft retd -time systems — systems where performance is 
degraded but not destroyed by failure to meet response time constraints. Systems in which failure to meet 
response time constraints leads to potential complete system failure are called hard real-time systems. Under 
these definitions, the UAV controller is a lmrd real-time system under which missing a deadline could lead 
to complete loss of control. Therefore deadlines, once established, become constraints inside which the 
system must operate completely. 

To meet these constraints, three measures of time, when applied to real-time systems, must be 
carefully managed: response time, survival time, and throughput [Sav85]. Each is defined below. 
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a . Response Time 



Response time is the time the computer takes to recognize and respond to an external event. 
This is the most important time measurement in control applications. If events are not handled in a timely 
fashion, the system may literally go out of control. The UA V must not only respond to pilot commands, but 
must continually monitor feedback signals from the servos and inertial navigation equipment to determine if 
the response resulted in the correct, desired effect. Experimental evidence suggests that a total response time 
from pilot input to final movement of control surfaces cannot exceed 100 msec without loss of positive flight 
control by the pilot [Kam93]. 

b. Survival Time 

Survival time is the time spttn during which data is available to be read. Since flight data is 
stored in a buffer, the data may be read at any time that the buffer is not being written to. Read/write cycles, 
therefore, must be sufficiently offset such that the reading and writing of the same data will not happen 
simultaneously. The next consideration, then, is the validity of the data. Since the aircraft is anticipated to 
move at speeds of up to 150 kts, it is important to have the latest sensor data available for every control cycle. 

c. Throughput 

Throughput is the total number of events which the system can handle in a given time period. 
For example, a communication controller may have a throughput expressed in characters per second. Since 
a hu ge amount of data must be relayed to the ground, the radio datalink must not be allowed to become a 
bottleneck which could slow the central processor. The data stream must also be managed to flow evenly, so 
that there are not bursts of data in excess of the clutnnel capacity interspersed among long periods of under- 
utilized capacity. In analog to digiutl (A/D) conversions, the bandwidth of the digital signal (equal to the 
product of the sampling rate mid the sampling width in bits) is usually much greater than the bandwidth of its 
analog eounterp;irt. Accordingly, the UA V A/D processes must be fast enough to provide fresh, accurate data 
at the frequency needed by the conUoller. 

2. Structure Taxonomy 

The simplest kind of software structure for a real-time system is a polling loop . The program 
examines (polls) each of its inputs in turn to determine whether an event has occurred which requires a 
response. This structure would be sufficient for the UAV if all polling was done at the same frequency. Since 



9 



this is not the case, a more complex, event-driven structure is needed. Event driven systems have three main 
types: interrupt driven, multi-tasking, or multi-processing (multiple processors) [Sav85]. 



a. Interrupt Driven 

In an interrupt driven system, counters are used to keep track of inter-process timing, 
generating <in interrupt when it is time to begin a new cycle. At the occurrence of an interrupt, the controller 
saves its current suite on the stack ;ind jumps to the appropriate interrupt service routine (ISR). If the timer 
generates an interrupt at regular intervals, Jind if the ISR is replaced by the control loop routine, it can be 
assured that the control loop will be executed regularly and consistently. However, for this to work, the 
execution time of the control loop must not exceed the interrupt time interval, or the subsequent ISR 
execution will interrupt the current ISR execution, resulting in a backlog of pending processes on the stack 
and, eventually, a system crash. To get the most from each control cycle, the task load resulting from each 
cycle should be kept as level as possible. 

b. Multi-tasking 

Task management could be delegated to the operating system if a multi-tasking environment 
was adopted. Multi-tasking, however, requires a large amount of processor overhead and brings with it its 
own unique problems when multiple tasks tire forced to work with the same data. Since multi-tasking is not 
available on the present operating system, this option was not considered. 

c. M ulti - pro cessing 

To a certain degree, the UAV will have multiple processors, as mentioned in the 
assumptions. The benefit of multi-processing is in the ability to take the processing load for these functions 
off the central controller and to have them performed by a processor that is specially designed for that task. 
It is important to ensure that these auxilkiry processors can access the same data buffers and to configure 
memory access such that no two can read/write the smne data simultaneously. 

3. Programming Language 

"C” was chosen as the prognunming language for this project since it is almost unique among the 
high-level compiler languages in that it does not (usually) come in between the programmer and the machine. 
If something can be done in assembly language, there is usually a way to express it in C [Sav85]. For 
example, in C one c;ui directly lminipulate machine registers. I/O addresses can be written to directly. 
Interrupt handling is also possible. Interrupt vectors can be inspected and modified, and BIOS interrupts can 
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be executed by a system call. Memory allocation can be directly controlled, and bit-level programming is 
possible. For any applications that cannot be completed in C, assembly language could be used. 

4. Fault Tolerance 

Fault tolerance, or system robustness, is the ability to recover from errors or system failures. With 
an interrupt-driven system, provisions must be made for detecting and covering for a missed deadline. This 
c;in be done by spatial or temporal methods [Lap92]. Spatial fault tolerance includes redundant hardware and 
softwtire systems. Temporal fault tolerance involves careful design of algorithms to compensate for missed 
deadlines. Since hardware on the UAV must be kept to a minimum, most of this redundancy must occur in 
the sof tware. Although this will add to the overall complexity and detract from the overall efficiency of the 
system, the nature of the mission requires this redundancy. In addition, execution time for the fault tolerance 
overhead must not cause timing constraint violations in an otherwise correct system [Nel92]. Timing, 
execution mid resource constraints dictate the following provisions for any module, regardless of the language 
that is used [Sta88]: 

• Modules should have predetermined and bounded execution times. 

(recursion and loops must be used carefully) 

• The use of dynamic structures should be controlled. 

• For predictable system behavior, provision should be made for all known types of exceptions. 

In addition to the norimd programming exceptions, the RTE for the UAV also has to deal with external 
malfunctions, such as equipment htilure, manual system reset, or loss of communication with the ground 
station. 

C. AN ESSENTIAL MODEL 

From the foregoing descriptions and specifications, it is possible to construct an essential model of the 
system, including a context diagram, an event list, leveled data-flow diagrams and state transition diagrams 
[You89]. Process specifications may be gleaned from the requirements discussed previously. 

1. Context Diagram 

It is necessary for the controller to interact with many varied components, as evident from the 
system block diagram. The context diagram in Figure 11-2, shows the context in which the controller must 
operate. The circle in the center represents the controller. Entities diagrammed outside the circle represent 
systems outside of the controller's realm of direct control, even though the controller communicates and 



dictates timing constraints with them. The buffer, datalink, and track log, diagrammed with a line above and 
below, represent data storage requirements. The arrows represent the transfer of data between systems. 




Figure II-2: Context Diagram for UAV Controller 



2. Data-Flow Diagrams 

Data-flow diagrams (DFDs) <ue graphical representations depicting the system as a network of 
functional processes mid manifesting the interactions of data flowing between those processes. Although just 
one of mmiy modeling tools, DFDs me commonly used for operational systems in which the functions of the 
system me of pmamount importance and more complex than the data that the system manipulates [You89]. 
The top level DFD is followed by sub-level DFDs that further break down the functionality of the top-level 
processes. 
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a. Top Level 



The top level data-flow diagram (DFD) for the UAV shows the interaction of all of the major 
processes. As shown in Figure 11-3, the controller responds to pilot commands or waypoints, determining 
control actions <'tnd providing feedback to the pilot’s control display, which completes the control loop. 




Figure 11-3: Top Level Data-Flow Diagram for UAV Controller 



n 



b . Single-Process Sub-Level Data-Flow Diagrams . 

Many processes in the top level DFD have only one process in their sub-level which just 
explains the function of the top-level process in more detail. For example, the following processes simply 
read data from a buffer or A/D port and p;tss it on without processing: 

4.1 = Read digihil representation of fuel level from A/D port. 

5.1 = Read digital INS sensor data from buffer. 

6.1 = Read digital GPS fix data from buffer. 

7.1 = Read digital representation of Non-INS sensor data from A/D port. 

12.1 = Record position in Track Log. 

Three other sub-level DFDs can be described by one process; however, that this process is 
slightly different depending on the mode of flight. The UAV can be flown directly by a pilot using joystick 
control or autonomously following a pre-established list of latitude/longitude/altitude waypoints. 



TABLE II- 1 : Process Comparison by Flight Mode 



Process 


Direct Control Mode 


Autonomous Flight Mode 


2.1 


Read joystick position 


Retrieve last/next waypoints 


3.1 


Convert composite com- 
mand into vectored com- 
mands for each of 3 
reference axes (X,Y,Z) 


Calculate trackline of accept- 
able positions between the two 
given waypoints. 


10.1 


Call Linear Quadratic 
routine (Assumption 1) 
to determine corrective 
control surface positions 


Calculate corrective trackline 
and, (10.2) call Linear Qua- 
dratic routine to determine cor- 
rect control surface positions. 



c. Multi-Process Sub-Level Data-Flow Diagrams 



Lastly, the multi-process sub-level DFDs are shown below: 




Figure II-4: Process 1.0, Update Control Display 
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Multi-Process Sub-Level Data-Flow Diagrams (con’t): 
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Multi-Process Sub-Level Data-Flow Diagrams (con’t): 



Note: 

This must be 




Figure II-7: Process 11.0, Generate Servo Commands 



3. Event List 

The event list looks deceptively simple. All events are temporal with the exception of 
asynchronous joystick inputs from the pilot, but since the command inputs are polled, this event also becomes 
temporal. Each event is either part of the control cycle or runs on its own frequency which would be an even 
multiple of control cycles. The challenge is to keep cycles of different durations from becoming out of synch 
and infringing on each other's resources. The controller must handle the following event parameters: 

Pilot inputs new joystick command. 

Pilot commands must be polled once per control cycle. 

INS data needs to be read once per control cycle. 

GPS input needs to be read once per second. 

Non-INS data needs to be read once per control cycle. 

Each of eight control surface servo command pulses must be generated each control cycle. 

The throttle servo command pulse must be generated once per second. 

The fuel level needs to be read every 60 seconds. 

The control display must be updated at least twice per second. 
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4. State Chart 



After considering many possible formats to depict state transition information, state charts 
appe<tred to best represent the organization of the UAV controller. Developed by D.H. Harel, et al [Har90], 
state charts combine the state transitions of sumdard state transition diagrams with process depth typically 
represented in Wiirnier-OiT diagrams and then add elements of orthogonality and communication. 
Orthogonality, represented by a dashed line, indicates separate tasks, and communication, represented by 
<utows, is a method for blowing different orthogonal processes to react to the same event fLap92], 
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D. CHAPTER SUMMARY 



As an unmanned vehicle, the UAV developed at the Naval Postgraduate School is completely 
dependent upon its automated systems to provide control of the aircraft in flight. Directing the execution of 
these automated systems is a controller running a Real-Time Executive program. The correct operation and 
real-time coordination of till functions on hom'd the aircraft depends on their interaction with this controller. 

At present, the UAV is designed to have iin on board GPS receiver, an inertial measurement device, and 
other in-flight sensors. Appropriate data must be selected from this navigation suite, filtered, and analyzed 
to determine the current state of the aircraft at any given time. This state may have to be converted into a 
different referential coordinate system. Processing this state via appropriate control algorithms will yield 
corrective positions for the available control surfaces and the throttle. These controls are moved by pulse- 
modulated servos, which require a pulse of a specified width be generated and output at a precise time. Pilot 
commands must be received mid the aircraft state may be transmitted through a communication link, using 
appropriate protocols. Data acquisition, processing, and I/O must be repeated at various intervals and 
coordinated through a Real-Time Executive (RTE) software program. This RTE is driven by a periodic 
interrupt and must be robust. The main challenge is to coordinate the complex scheduling of these executed 
functions to yield smooth and positive control of the UAV. 



IS 



III. HARDWARE 



Hjirdware selection represents a challenging task. Choosing from the myriad of possible systems and 
configurations, each with their own cost, advantages, and disadvantages, it is easy to underestimate the 
ultimate significance of that selection. Indeed, the hardware selected determines most, if not all, of the 
system’s limitations. It impacts the flexibility of the system and the programmer’s control over the system. 
It determines the method by which things earn be accomplished on or by the system. 

For the UAV controller, the selection of hardware was largely made prior to this research. In general, 
it wjls constrained by the following criteria: 

• The manufacturer should be from the United States, local if possible. 

• All hardware should come from the same manufacturer, for interoperability purposes. 

• Therefore, the manufacturer should offer hardware to meet all requirements. 

• The composite hardware solution should be modular, for ease of upgrading and maintenance. 

• The fcirdware must be immediately available (not under development). 

• The hardware could operate on a standard +/- 5 V and +/- 12V power supply. 

• The composite hardwire solution would fit within the space available on the UAV. 

• The composite hardwjue solution would have minimal weight. 

• The hjtrdwtire could execute commercially available software, including a C compiler. 

The reasoning behind choosing an American manufacturer was that if there were any hardware related 
problems, an American manufacturer, especially one with an office in the local area, would be easiest to 
contact ;wd could provide the quickest response to requests for technical assistance. A specific operating 
system was not originally selected, but defaulted to MS-DOS because of the low cost and wide availability 
of compatible hardwjire and software. The choice of MS-DOS precludes the use of multi-tasking scheduling 
strategies, but it was determined that multi-tasking would not be required, at least for the first iteration of the 
controller. 

Ultimately, Jill controller lutrdware was purchased from American Advantech, Inc. Their offices and 
technical sutff ;ire located in Sunnyvale, CA. This chapter delineates the most prominent features of the 
luirdwjire selected. It lists selected specifications for the chosen hardware and discusses the configuration of 
that hjirdwjire as designed for the controller applications. These configurations have been carefully selected 
to get maximum performance and complete interoperability out of each system component. Numbers listed 
jire Advantech model numbers. Technicjil data sheets are given in Appendix C. 
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A, SYSTEM OVERVIEW 



Figure III- 1 shows the configuration and connectivity of the overall hardware system. The oval shape 
represents components that are needed for development only and are detached prior to installation. The 
remaining components must be mounted on the UAV, most inside the control pod designed by Moran 
[Mor93J. Racetrack shapes represent sensor and navigation subsystems, most designed through the research 
of other students and incorporated into this controller design. Rectangular shapes indicate circuit cards or 
power supplies, most from Advmitech, that comprise the central part of the controller. The specifications and 
configuration of each component is described in this chapter in sufficient detail such that a new user would 
be able to recreate <tnd undersumd the present luirdware system. 




Figure III-l: Overall Hardware System Configuration 



B. PCA-6108: PASSIVE BACKPLANE 

This is priimtrily :m external bus, facilitating communication and data transfer between all other 
hcirdwiire components. The other computer circuit bo;trds plug directly into each of the eight, PC/AT 
compatible expmision slots. This cud has a heavy duty, standard block connector for the power supply, 
nuiking +5V, + 12V, -12V, and system ground available to all cards. 
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C. PCA-6146: CPU CARD 



1. Specifications 

This bcxird contains the central processor, an Intel 80486 running at 33 MHz with 8Kbytes of 
cache on-chip, 256 Kbytes of 25ns double cache memory and 16 Mbytes of DRAM. Also included on the 
botird ;ire ancilkiry electronics to support processor functions, such as the Peripheral Interrupt Controller 
(PIC), Universal Asynchronous Receiver ;ind Transmitter (UART) and counter/timer chips. The board 
interfaces with the backplane through a 32 bit ISA bus operating at 8 MHz. Control circuits on the board 
support two floppy disk drives, two IDE hard disks, two RS-232 nine-pin serial ports, one 25-pin parallel port, 
and a keyboard port. Signific;int for this research, it features a 4-bit (15 level) interrupt vector and a 
programmable watchdog timer. The watchdog timer ensures that the CPU will be reset if a program cannot 
be executed normally, which is useful in retd-time systems where a program or power glitch could lock up 
the system. The maximum power requirement for this board is approximately 2.5 A at +5 V. 

2. Configuration 

The CPU atrd has been configured to support parallel port LPT2, serial ports COM1 on the upper 
port and COM2 on the lower port, and the floppy disk controller. To accomplish this, the J 1 jumper pins must 
be set as shown in Table III- 1 . Next, although the controller functions without a hard disk, one is needed for 
software storage during the initial prognimming. Thus, jumper JP17 must be enabled (open). The watchdog 
timer is enabled by closing jumper JP22 tind leaving JP23 and JP24 open. The timer interval is set by closing 
either J P 1 9, JP20, or JP21. Due to the nature of this application, a timeout of 1.5 seconds was selected. 
Should a power drop, softw;tre bug, or infinite loop halt the system, the aircraft would be without positive 
control for a maximum of 14 seconds, including a total rebooting time of 12 seconds. 

When connecting the CPU card to an external panel display, attach the lead wire for hard disk 
indicator light (usually red and black) to the HD connection next to the red LED at the top of the CPU card. 
Attach the lead wire for the turbo light (usually yellow ;ind black) to JP5. The lead wires from the reset switch 
(usutdly red and black) connect to JP4, and the keylock connection is made at made at JP3. Pins 3 and 5 of 



21 



JP3 are ground connections, so the black wire should be at the bottom of the connector. Incidentally, pin 1 
of JP3 is LED power, and pin 4 controls the keyboard lock. 



TABLE IIH: CPU Card Jumper Settings 



Jumper 


Setting 


Jumper 


Setting 


JP1/1 


Close 1-2 


JP14 


Close 2-3* 


m/2 


Close 1-2 


JP15 


Open* 


jp i/3 


Close 1-2 


JP16 


Closed* 


JPl/4 


Close 1-2 


JP17 


Open 


JPI/5 


Close 1-2 


JP18 


Open* 


JP1/6 


Close 1-2 


JP19 


Closed 


JP1/7 


Close 1-2 


JP20 


Open 


JP7 


Close 2-3* 


JP21 


Open 


JP8 


Close 2-3* 


JP22 


Closed 


JP11 


Close 2-3* 


JP23 


Open 


JP12 


Close 2-3* 


JP24 


Open 


JP13 


Close 2-3* 







* Denotes factory setting 

3. Basic Input Output System (BIOS) 

For the system to work properly, the actual h;irdware and memory configuration must match the 
setup configured in the non-volatile BIOS chip. This is a CMOS memory chip by American Megatrends, Inc. 
which stores the system configuration and is read by the processor each time the system reboots. To access 
the BIOS data, press the DEL key during the initial stages of the bootstrap process, while the processor is 
checking the avtiilable memory. The program will present a main menu from which the user may choose 
CHIPSET setup, standard CMOS setup, or advanced CMOS setup. For this research, no changes are 
necessary to the CHIPSET setup; till factory default values are used. 
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In the stiindard CMOS setup, values entered must correspond to the actual hardware in use. For 
this research, a 102 MB hard disk and a 1.44 MB, 3.5 inch floppy drive are used. Accordingly, hard drive C 
is set to USER TYPE 47. This should correspond to the following data fields: 



TABLE III-2: Hard Drive C Parameters 



Cyln 


Head 


WPcom 


LZone 


Sect 


Size 


1024 


12 


1025 


1025 


17 


102 



When booting from the PCD-890 RAM Disk, no actual hard disk is used, so hard drive C must be changed 
to Not Installed. Hard drive D should always be set to Not Installed , floppy drive A should be set to 1.44, 
and floppy drive B may be set appropriately, if one exists. 

Among the many p; train eters set in the advanced CMOS setup, a few are important. The HD Data 
Area should be set to 0:300. This should not be changed unless a different hard disk is used or if the present 
hard disk is reinitialized. The System Boot Seq should be set to C: A ;, which forces the system to boot off 
the h:trd disk, if one exists. Finally, ;dl cache should be enabled, all video ROM shadow-RAM should be 
enabled, all adapter ROM shadow-RAM should be disabled, and the system ROM shadow-RAM should be 
enabled. 

1). PCD-890: RAM Disk 

1. Specifications 

The PCD-890 is a solid-state disk emulator with a capacity up to 12 MB, using EPROM, SRAM, or 
Flash memory chips. For this resc;irch, 24 Sony 581000P 128 KB SRAM chips were used to create a 2.88 
MB emulated disk. Replacing mechanical drives with the RAM Disk not only allows data retrieval to be 
accomplished five times faster, but the RAM Disk is also much less susceptible to damage from motion or 
vibration. Two PCD-890's may be instiled on each system, and each PCD-890 has two memory banks that 
may be configured as either one or two virtual disks. Each virtual disk can be configured as drive A, B, C, 
or D which are fully software compatible with mechanical drives with no additional software development. 
Each hom'd features a 3.6 V rechargeable lithium battery that keeps the SRAM charged and lasts up to six 
months. Memory loss is possible if this battery is iillowed to run down; however, there is a connection at CN 1 
lor an optional external battery power. Each card requires only 16 KB of system memory. 



23 



2. Configuration 

The PCD-890 comes with a utility program which is used to load the on board BIOS chip with the 
present configuration. This configuration is dependent on the position of various dip switches and jumpers. 
Jumpers JP1 and JP5 select the type of chips installed in each bank. Both of these should close the connection 
between pins 2 and 3 to denote SRAM. JP10 and JP1 1 set the size of the installed chips. These should also 
close pins 2 and 3 to denote 128 K or larger. Because there is only one PCD-890 installed, the JP9 jumper 
should close pins 1 and 2. To enable the SRAM battery, close pinsl and 2 on JP4. JP8 sets the interval of 
the watchdog timer, which is not used on this citrd. 

Dip switches S W 1 and S W2 are used to enable each bank and set its drive designation. Position 
1 and 2 set the designation. For normal operation, bank 1 must be enabled, unprotected, and set to drive A 
so that the computer will boot from the RAM Disk in the absence of a hard disk (Recall this bootstrap order 
was established in the BIOS of the CPU card.). Since it is desired to have one contiguous memory space, 
biuik 2 must be disabled and called something other than drive A. Table III-3 shows the switch settings used 
lor this configuration. 



TABLE III-3: Switch Settings for PCD-890 



SW1 


SW2 


1 


2 


3 


4 


1 


2 


3 


4 


On for A 
Off for C 


On 


On 


On 


On 


Off 


On 


Off 



During system development, it is often desirable to use both the RAM Disk along with a hard drive 
C and a floppy drive A. In this case, designate the RAM Disk as drive C by turning off switch 1 of SW1. If 
the PCD-890 is internally designated the same logical name its a hard disk existing in the same system, MS- 
DOS will automatically assign the PCD-890 to the next available DOS drive, in this case drive D. Note that 
the utility prognun will continue to refer to each bitnk according to the jumper setting, not its DOS drive 
designation. Also, the BIOS on the CPU etird must be updated to correctly reflect the presence or absence of 
the actual hard drive. 

Finally, S W3 sets the memory and I/O addresses tissigned to this card. These have been carefully 
selected to avoid conflicts with other hardwtirc and system services. If two PCD-890’s are installed, they 
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must be set to occupy the smne memory address (positions 1, 2, and 3 are the same on both cards), but 
different I/O addresses (positions 4, 5, and 6 cannot all be the same). SW3 should be set as follows: 



TABLE III-4: Switch Settings for PCD-890 SW3 



1 


2 


3 


4 


5 


6 


Off 


On 


Off 


On 


On 


Off 



The utility program can be invoked by executing the file named 890 in the PCD-890 directory. 
Once the switches and jumpers have been properly set, the utility program should mirror that configuration. 
Drive A is listed as 5 1 2KB SRAM with a disk size of 2.88 MB. All other entries should read Not Installed . 
Pressing ESC will exit the program and load the configuration into the BIOS chip. 

Once properly configured mid plugged into the backplane, the PCD-890 will automatically install 
itself in memory during the booting sequence. The only indication will be a message similar to Figure III-2 
Hashed on the screen for less than one second in between the RAM check sequence and the execution of the 
AUTOEXEC.bat file. To view this screen, press the Pause key to halt the bootstrap process. 

PCD-890 RAM/ROM DISK BIOS Rev. B1 (c) Copyright Advantech Co., Ltd. 1992 
Configuration. I/O MEMORY 

Drive A: 2.88M RAM Disk formatted (write protect OFF) 0240 D400 
BATTERY IS GOOD 

Figure III-2: PCL-890 Installation Confirmation Message 
E. PCL-744: SERIAL I/O CARD 
1. Specifications 

The PCL-744 is an intelligent serial data communications interface card. It provides eight 
asynchronous, full-duplex RS-232 or RS-422 ports per card, and up to four PCL-744 cards may be used 
concurrently. It is equipped with a V20 (8088 compatible) 8 MHz CPU, which relieves the central processor 
of all data handling and I/O llow control tasks. Transmit mid receive queues are stored in a 64 KB dual-port 
RAM buffer, which frees main memory and prevents data loss. Dual-port refers to the fact that data can be 
accessed by both the central processor and the on board CPU. This memory-mapped data transfer is generally 
much faster than standmd memory I/O with data copying. Each card maps to only 8 KB of system memory. 
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The PCL-744 has a single DB64 female port which connects to a special “octopus’' cable 
branching out into eight DB25 male connectors. Each of the eight ports features complete modem flow 
control signals (RTS, CTS, DSR, DTR, and DCD) and operate at a programmable communication rate 
ninging from 50 to 38,400 bps. The PCL-744 uses four 2681 DU ART (Dual Universal Asynchronous 
Receiver ;ind Transmitter) devices, with each 2681 controlling two ports. These two ports share one baud 
rate divider, which is clocked by a 3.6864 MHz crystal. Baud rates may be selected for each of the two 
channels independently, but because of the s limed divider, both rates must be from the same group: 



TABLE III-5: Baud Rate Groups (bps) 



Group 1 


1200. 2400, 7200, 9600, 38400 


Group 2 


1200, 1800, 2000, 4800, 9600, 19200 



The PCL-744 selects its IRQ level automatically in software and requires a maximum of 1.5 A at 
5 V, 120 mA at 12 V, :ind 170 mA at -12 V, the latter necessary for RS-232 signalling. 

2. Configuration 

The PCL-744 has no jumpers or switches. Configuration options such as the number of cards, 
IRQ channels, port numbers, and memory buffer starting addresses are all selected using the setup program. 
To run the setup program, execute the program named SETUP in the PCLS-802 directory. Choose the 744 
intelligent e;u*d choice to get to the PCL-744 setup screen. On this screen, set the select IRQ number to JO 
hex mid the select dual port bmik to AUTO. The start port should be set to 03 . This is because the two COM 
ports on the CPU aird become ports 1 and 2 by default. Pressing page-down gives access to the port 
configuration menu. The Group Edii function ensures that ;dl ports are configured identically. Ports 3 
through 10 correspond with octopus cable connectors 1 through 8, and are configured as shown in Table HI-6. 

To install the PCL-744 driver, execute the file 744-DRV.exe in the PCLS-802 directory. If it 
installs correctly, the following message appears: 

PCL-ComLib Communications Driver (Ver 3.00) 

PCL-744 Multiport Card 1 : No [05477] Bank [C800] Port [03-10] IRQ 10 

Device Driver Setup O.K. 

Figure III-3: PCL-744 Installation Confirmation Message 

Executing the file STD-DRV.exe will also enable control of COM1 and COM2. Both of these 
executions :ire done automatically from the AUTOEXEC.bat program during system bootstrap. 
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TABLE III-6: PCL-744 Serial Port Settings 



Ext RxD Buf Size 


2K 


Baud Rate 


9600 


Character Length 


8 


Step Bits 


1 


Parity 


None 


DTR Output State 


Off 


RTS Output State 


Off 


CTS Flow Control 


No 


RTS Flow Control 


No 


Tx XON/OFF Cntrl 


No 


Rx XON/OFF Cntrl 


No 



F. l’CL-812P(i: ENHANCED MULTI-LAB CARD 
1. Specifications 

The PCL-812 is a high speed, multi-function data acquisition card used primarily in this project 
to accomplish analog to digital (A/D) data conversions. It features: 

• 16 single-ended jmalog input channels 

• Switch selectable bipolar an: dog input voltage ranges 

• A programmable Intel 8253-5 timer to provide internal pacer (trigger) pulsing 

• Choice of internal or extern:d reference voltages 

• A PCLD-780 wiring terminal bre:ikout bo:ird for ease of connection 

• Callable softw:ire drivers for :dl c:ird features 

• TTL compatible I/O signal levels 

Single-ended :uialog inputs require only one signal wire for each channel. The voltage is 
measured with respect to common (system) ground. A signal source measured with respect to a reference 
other th:in common ground is a floating source. For these signals, a second input called analog ground 
(A.GND) is available. 

The PCL-812 uses an industrial smndard 12 bit successive approximation converter (HADC574Z) 
to convert analog inputs. Typicul A/D conversion time is 25 usee. Because an 8 bit register cannot 
accommodate all 12 data bits, the A/D data is stored in two registers located at the base address +4 and +5. 
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The least significant bits ;u*e in positions 0 (ADO) through 7 (AD7) of BASE +4, and the most significant bits 
are in positions 0 (AD8) through 3 (ADI 1) of BASE +5, with AD11 being the most significant. Other 
important I/O addresses ;ue shown in Table 111-7. The PCL-812 requires 16 consecutive bytes of address 
space and typically draws 500 mA at +5V, 50mA at + 12V, and 14mA at -12V. 



TABLE III-7: PCL-812 I/O Address Map 



Location 


Read Function 


Write Function 


Base Address 


Counter 0 


Counter 0 


Base + 1 


Counter 1 


Counter 1 


Base + 2 


Counter 2 


Counter 2 


Base + 3 


Not Used 


Counter Control 


Base + 4 


A/D Low Byte 


Ch 1 D/A Low Byte 


Base + 5 


A/D High Byte 


Ch 1 D/A High Byte 


Base + 6 


D/I Low Byte 


Ch 2 D/A Low Byte 


Base + 7 


D/1 High Byte 


Ch 2 D/A High Byte 


Base + 8 


Not Used 


Clear Interrupt Request 


Base + 9 


Not Used 


Voltage Gain Control 


Base +10 


Not Used 


Mux Control 


Base + 1 1 


Not Used 


Mode Control 


Base + 1 2 


Not Used 


Software A/D Trigger 


Base + 1 3 


Not Used 


D/O Low Byte 


Base +14 


Not Used 


D/O High Byte 


Base +15 


Not Used 


Not Used 



Configuration 

The base address for the PCL-812 is selected using the first six switches of SWL located at the 



top of the circuit bcKird. These should be set as shown in Table III-8, giving an I/O address of Hex 220. 

TABLE III-8: Switch Settings for PCL-812 SW1 



1 


2 


3 


4 


5 


6 


7 


8 


On 


On 


On 


Oil' 


On 


On 


On 


On 
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Switches 7 mid 8 of S W 1 control the number of wait states added to the PCL-812 to achieve stable 
data tnuisfer. It can be configured with zero, two, four, or six wait state delays for each transfer of data. Both 
switches turned on selects zero delay. Jumpers are used to select the remaining configuration options. 
Table 111-9 shows the present settings and their function. 



TABLE III-9: PCL-812 Jumper Settings 



Jumper 


Setting 


Function 


JP1 


Close 1-2 


Use internal A/D conversion trigger 


JP2 


Close 1-2 


Use internal 2 MHz clock for counter channel 0 


JP3 


Close 1-2 


Use internal voltage (JP8) for D/A reference on Ch 1 


JP4 


Close 1-2 


Use internal voltage (JP8) for D/A reference on Ch 2 


JP5 


Close contact 5 


Select IRQ5 to signal A/D completion 


JP6 


Close contact X 


Select no DMA data transfer (DRQ Channel) 


JP7 


Close contact X 


Select no DMA data transfer (DACK Channel) 


JP8 


Close 2-3 


Use -5 V for internal D/A reference voltage 


JP9 


Close 2-3 


Select +/- 5V for maximum A/D conversion range 



If JP9 is set to +/- 5 V, the analog input ranges available for A/D conversion are +/- 5 V, +/- 2.5V, 
+/- 1.25V, +/- 0.625V, or +/- 0.3 125 V, dependent on a software gain code parameter. These ranges could be 
doubled by setting JP9 to +/- 10V, but only if Vcc of the system power supply is strictly greater than 12V, 
otherwise A/D conversions will not be correct. The output of the present power supply is only 1 1.8V. 

Analog connections ;tre made through connection ports CN 1 and CN2 on the slot edge of the card. 
Figure 111-4 shows the pin alignment for each connector. For this research, a PCLD-780 wiring terminal 
bre;tkout bomd was used to connect signal wires to the ports through ribbon cables. 
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A.GND 


V.REF 1 


17 


18 
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Figure II 1-4: PCL-812 Connection Port Pin Alignments 
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Prior to using the Lab Card, it is necessary to install the PCL-812 driver by executing the file 
PCL 8l2.exe in the PCL-812 directory. The computer will confirm correct installation with the message, 
“PCL-812 Driver Version 1.0 is now installed.” This execution is also done automatically from the 
AUTOEXEC.bat program during the system bootstrap process. 

3. Calibration 

For accurate results, the A/D inputs must be properly calibrated. Five variable resistors (VRs) on 
the PCL-812 allow accurate adjustment. VR3 and VRS are used for A/D adjustment, VR1 and VR2 are used 
for D/A adjustment, and VR4 adjusts the programmable amplifier offset. Executing the calibration program 
in the PCL-812 directory, the user must specify the input voltage range setting and channel number. Then 
the program will guide the setting of the prognunmable amplifier offset, the A/D offset, and the A/D gain. It 
is importiuit to note that the calibration on one A/D range may cause a small offset on other ranges, so it is 
suggested to calibrate the A/D range for which the best accuracy is required. 

<i. PCL-830: COUNTER/TIMER CARD 

1. Specifications 

The PCL-830 is a multi-function counter-timer and digital I/O card used primarily in this project 
to generate high -resolution, programmable-duty-cycle square waves used to drive the Pulse Width 
Modulation (PWM) servos, which move the aircraft's throttle and control surfaces. It provides ten 
independent 16 bit up/down counters, a I MH/ crystal oscillator time base, and 16 bit TTL/DTL compatible 
input and output ports. In the heart of the PCL-830 are two Advanced Micro Devices AMD9513 System 
Timing Controller (STC) chips used for all counting and timing functions. These STC chips are highly 
versatile and adaptable to many real time applications, including 

• Retriggerable digital timing functions 

• Time of day clocking 

• Coincidence akirms 

• Complex pulse generation 

• Frequency shill keying 

• Event count accumulation 

The STC is addressed by the main processor through two I/O ports; a Control port and a Data 
port. The Control port provides direct access to the Status and Command registers, as well as allowing the 
user to update the Data Pointer register. The Data port is used to provide the data used to communicate with 
all other addressable internal locations. The Data Pointer register controls the Data port addressing. Among 
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the registers' accessible through the Data port are the Master Mode register and five Counter Mode registers, 
one for each counter. The Master Mode register controls the programmable options that are not controlled 
by the Counter Mode registers. Each of the five general purpose counters is 16 bits long and is independently 
controlled by its Counter Mode register. Through this register, the user can software select one of 16 sources 
as the counter input, a variety of gating and repetition modes, up or down counting in binary or binary coded 
deciimil (BCD), and active-high or active-low input and output polarities. Associated with each counter are 
a Load register and a Hold register, both accessible through the Data port. The Load register is used to 
automatically reload the counter to any predefined value, thus controlling the effective count period. The 
Hold register is used to save count values without disturbing the count process. 



The PCL-830 requires 6 consecutive bytes of address space, as follows: 

TABLE III- 10: PCL-S30 I/O Address Map 



Location 


Read Function 


Write Function 


Base Address 


9513 Chip 1 Data In 


9513 Chip 1 Data Out 


Base + 1 


9513 Chip 1 Command Register 


9513 Chip 1 Status Register 


Base + 2 


9513 Chip 1 Data In 


9513 Chip 1 Data Out 


Base + 3 


9513 Chip 1 Command Register 


9513 Chip 1 Status Register 


Base + 4 


Digital Output Bits 0 - 7 


Digital Input Bits 0 - 7 


Base + 5 


Digits Output Bits 8-15 


Digital Output Bits 8 - 15 



All ports are 8 bits (one byte) wide. When loading data that is longer than 8 bits - the digital data 
used to generate PWM signals for this project are 12 bits long -- the low byte must be loaded first, followed 
immediately by the high byte. 

2. Configuration 

The base address for the PCL-830 is selected using the first six switches of SW1, located at the 
top of the circuit board. These should be set as shown in Table III- 1 1 , giving an I/O address of Hex 210. 

TABLE III- 11: Switch Settings for PCL-830 SW1 



1 


2 


3 


4 


5 


6 


7 


8 


On 


On 


On 


On 


Off 


On 


On 


On 
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Switches 7 and 8 of SW1 control the number of wait states added to the PCL-830. It can be 
configured with zero, two, four, or six w<iit state delays for each transfer of data. Both switches should be 
turned on to select zero delay. There is only one jumper on the PCL-830. This jumper (JPI) should close 
contact 3 to select IRQ3 as the interrupt level. The interrupt is not used in the present configuration, but to 
use this interrupt, set the Interrupt Enable (CN1 pin 18) low. The positive edge on the Interrupt Input (CNI 
pin 19) will then generate an IRQ level 3. 

Signal connections ;tre made through one of four 20 pin male connection ports. CNI and CN2, 
found on the slot edge of the card, are used to interface with the AMD95I3 STC chips 1 and 2 respectively. 
Figure III-5 shows the pin alignment for these connectors. For this research, a PCLD-780 wiring terminal 
bre<tkout bo;trd was used to connect signal wires to the ports through ribbon cables. The servos are attached 
by first connecting the red and black voltage reference wires to +5 V and GND. The white command wires 
are then connected to OUT 1 through OUT 10. 
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19 
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19 


20 
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Figure III-5: PCL-830 Connection Port Pin Alignments 
It is not necessttry to install tiny drivers prior to using the PCL-830; however, a counter on the 
AMD95 13 must be armed by sending an ARM command to the Control port before counting can commence. 
Once armed, the counting process may be further enabled or disabled using the hardware gating options. 
Additional commands tire provided to step an individual counter by one count, set and clear an output toggle, 
issue a soft ware reset, cle;ir ;ind sei special bits in the Master Mode register, and load the Data Pointer register. 

H. Global Positioning System (GPS) Receiver 

I. Specifications 

The Motorola GPS receiver used in this research, model PVT-6, is fully detailed by Twite 
[Twi94|. It is a fully automatic position finding system that determines and digitally transmits autonomous 
position, altitude, velocity, heading, satellite tracking status, and correct time in three different, user 
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selectable formats: Motorola ProprieUiry Biniiry Format, National Marine Electronics Association (NMEA- 
0183) Format, or LORAN Emulation Format. Each of the six parallel channels can find, track, and monitor 
one NAVSTAR satellite. If three satellites with adequate signal strength and bearing spread are available, a 
two-dimensional (latitude ;md longitude) fix is calculated. If four or more usable satellites are available, 
altitude c;in also be determined. Instantaneous speed and heading is determined by measuring signal doppler 
shifts, although without differential corrections, this information is prone to small errors. 

2. Configuration 

The GPS receiver module and its antenna are fully self-contained units that require no special 
configuration. The antenna plugs into the coaxial connector on the receiver module. Power and serial data 
connections ;ire made through a ten pin connector on the back of the unit. A special data cable has been 
manufactured to provide +5 V and GND to pins 2 and 3 respectively. Serial data communications use pins 8 
through 10 and terminate in a DB9 female connector. This is, in turn, connected to PCL-744 octopus cable 
number 2. 

I. INERTIAL MEASUREMENT UNIT (IMU) 

1. Specifications 

The IMU selected for this project was manufactured by Watson Industries in Eau Claire, WI. 
Model 1MU-600D uses vibrating element sensors to provide the following nine sensor readings: 



TABLE III- 12: IMU Data Output 



Sensor 


Scale Limits 


X-Axis Acceleration 


+3g to -3g 


Y-Axis Acceleration 


+3g to -3g 


Z-Axis Acceleration 


+3g to -3g 


X-Axis Anguktr Velocity 


+ 100 to -100 Degrees/Second 


Y-Axis Angukir Velocity 


+ 100 to -100 Degrees/Second 


Z-Axis Angukir Velocity 


+ 100 to -100 Degrees/Second 


Magnetic Heading 


N=7fff, E=c000. S=0000, W=3fff 


Bank Angle 


+60 to -60 degrees 


Pitch Angle 


+60 to -60 degrees 
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Each analog sensor reading is processed through a 16 bit A/D converter and the resulting digital 
representation of the signal is in two's complement format. To use acceleration as an example, 3g = Hex 7fff, 
Og = Hex 0000, ;ind -3g = Hex 80(X). In all, there are nine 2-byte words of sensor data. Each word of data is 
sent as a set of four ASCII characters (0-9 or ABCDEF) corresponding to the hexadecimal representation of 
the 1 6 bit word. This complete bank of data is terminated by a carriage-return and line feed, bringing the total 
size of one data reading cycle to 38 bytes. The sensor data is sent continuously at 9600 baud with one start 
bit, one stop bit, and no p;uity bit. At this speed, ignoring any overhead for data formation, a full data bank 
eould be received every 31.7 msec, or just over 31.5 Hz. 

The 1MU can also receive data. The receive line is used for calibration, so care should be taken 
to send only the following signals:. 

TABLE III-13: IMU Input Signals 



Signal 


Definition 


1 


Continuously send bank 1 data 
(Data described above) 


R 


Continuously send bank 2 data 


0 


Exit Initialization 


W 


Re-enter Initialization 



The IMU normally requires 43 minutes to warm-up and initialize. During initialization, the unit should 
not be moved for best accuracy. The IMU will send out the bank 1 data stream as it is initializing. 



2. Configuration 

The IMU is a fully self-contiiined unit with only one nine pin port for power and serial data connections. 
Table 111-14 shows the pin configuration. A special data cable has been manufactured to provide GND and 



TABLE III-14: IMU Pinout 



Pin 


Function 


1 


Power GND 


2 


+28 VDC 


3 


Signal GND 


5 


Signal Receive 


9 


Signal Send 
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+2X V power to pins 1 and 2 respectively and terminates with a DB9 male connector. This is, in turn, 
connected to PCL-744 octopus cable number 1. Although the manufacturer attests that the unit can operate 
with as little as 22 VDC supplied, it must be with respect to system ground for the serial communications to 
have the proper signal levels. Because of this the + 12V to -12V spread available from the system power 
supply cannot be used; a separate power supply was used for test purposes. Maximum power consumption 
is 250 mA at +28 V. 

J. DATALINKS 

Two different datalinks have been developed for the UAV so far. Both were commercial off-the-shelf 
(COTS) products that had to meet several criteria: 

• Cost limitations 

• Weight limitations 

• Power limitations 

• Size limitations 

• Stand;ird serial interface 

• Ability to transmit/receive beyond the line-of-sight 

• Frequency agility 

• H;irdware reliability 

• Adequate data throughput 

The first datalink solution was a X.25 packet radio terminal node controller (TNC) connected to a 19.2 
Kbps modem in combination with a UHF wide-hand transceiver developed by Reichert [Rei93]. This is a 
robust system that meets or exceeds almost every criteria. Reichert’ s estimate of required data throughput is 
accurate in scope, but may change slightly in the final design. For example, he lists the control refresh rate 
as 40 Hz while this controller operates at 32 Hz. He estimates 8 bits per servo update, while the present 
configuration uses 12: however, the present configuration could be reduced to 8 bits per servo with no 
noticeable chtuige in perlonmtnce. An updated throughput requirement estimate is shown in Figure III-6. 
Using this updated requirement, the capacity of this datalink, which yields 19.2 Kbps simplex or 9600 bps 
duplex, is exceeded. Possible solutions would be to reduce the servo input to 8 bits and to refrain from 
downlinking INS and non-lNS sensor data for every control cycle. 

The second datalink solution was a direct-sequence spread spectrum UHF datalink as developed by 
Bess |Bes94|. This datalink tilso used a modified X.25 protocol with a top transfer speed of 19.2 Kbps. It 
has prognunmable length packets and performs its own error correction and flow control. Spread spectrum 
transmission has the added advantages ol being less susceptible to jamming signals and may be operated 
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without an FCC license. The unit includes a serial data cable that terminates with a DB9 female connector. 



This is, in turn, connected to PCL-744 octopus cable number 3. 
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Figure III-6: Datalink Throughput Requirements for Ground Control 



The first daudink was not used in this resettrch because of its complexity and licensing requirements. 
The second datalink did not perform well in the laboratory environment, occasionally locking up or dropping 
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out of service for no apparent reason. Although configured for 9600 bps throughput, actual results were less 
than half of that. It also required cycling ihe power and manual configuration to be restarted. Once 
autonomous flight is achieved, the daialink will diminish in its importance, but as long as direct ground 
control is required, the daudink is the lifeline and the weakest link in controller communications. 

K. ANCILLIARY EQUIPMENT 

In addition to the <tforementioned h;trdw;ire integral to the controller itself, ancillary equipment was 
necessary to form the complete system. In order to control the UAV, servos and a source of power are 
needed. Any COTS model airplane servo motors could be used, as described by Stoney [Sto93], provided 
they generate sufficient torque to hold the control vanes position in the thrust stream. The servos used for 
this UAV were Futaba high torque model FP-S34. The red and black wires connect to +5 V system power 
and system GND respectively. The white command signal wire is attached to the PWM output signal from 
the PCL-830 counter/timer c;ird. The white feedback wire connects to one of the A/D analog input channels 
on the PCL-812 lab c;urd. Power for this resetirch project was generated by a standard AMAX 200 W power 
supply that provided up to 20 A at +5 V, 8 A at +12 V, and 0.5 A at both -5 and -12 volts, which was ample 
for idl h;irdw<'ire used. Power generation mid storage will vary according to the UAV design. Although not 
investigated in this resemch, it is a very technical problem that affects the operation of all hardware. 

A video graphics adapter (VGA) card linked with a standard VGA monitor and a Microsoft in-port 
mouse, together with the hard disk mid floppy drives represented the detachable part of this system hardware 
which was necessity for system development only. Once the controller software was developed, it was 
transferred to the RAM Disk. The system was then configured to boot from the RAM Disk and automatically 
invoke the controller program. The keybojird and monitor are also detached prior to installation into the 
airframe; however, the so It w; ire must be modified slightly to accept user commands from the datalink prior 
to operation without the keybomd and monitor. 

L. CHAPTER SUMMARY 

This chapter gives a detailed description of the specifications of the hardware selected for the UAV 
controller, and the configuration details necessary to enable all equipment to interact together, including those 
subsystems developed by other students. Using this information, system users and follow-on researchers will 
know and undersmnd how the system was designed to operate and the configuration details necessary to 
reconstruct a similar system. For additional information about the specifications or operation of this 
lKtrdwiire, see Appendix C or the published user’s manuals. 
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IV. SOFTWARE 



Once the Imrdware has been selected, it is the software that actually shapes the operation of the 
controller. The hardwire mid software have a symbiotic relationship by which neither can function without 
the other. The software must operate within the confines of the hardware’s capabilities and configuration, and 
the hardware fulfills its tasks in a coordinated manner by talking its direction from the software. Software 
gives the system its function and its personality. It provides for the interface by which the user comes to know 
and recognize the system, it provides the transfer <tnd organization of all the data crucial to the controller's 
operation, and it coordinates the functions of and sets the cadence for the hardware components. Where 
hardware is the body, software is the life blood. 

This chapter will provide an overview of the scope of the software written for this research. Beginning 
from the origimd requirements, it will specify the conventions, definitions, and structures necessary to help 
the reader understand the code. It will detail the softwjire environment in which the software is designed to 
operate, and it will briefly describe the function of the various procedures. A complete listing of the code is 
included in Appendix A. 

A. OVERVIEW 

The UA V is a multi-faceted project bringing together many varied disciplines. Since the scope of this 
reseiuch was to design the Real-Time Executive (RTE) for a central controller, it required the assimilation of 
many sub-systems into one interoperable, cohesive, control system. These sub-systems were developed by 
other students as part of an ongoing development effort. Among the many sub-systems previously developed, 
this RTE was spec i flail ly designed to coordinate datalink development by either Bess [Bes94] or Reichert 
[Rei93], navigation system development by Twite [Twi94] and Hallberg [Hal94], servo control development 
by Merz [Mer92] and Moran [Mor93], iind aeronautical control algorithm development begun by Davis 
[Dav92) and Brynestad (Bry92), and continued more recently by Bolyard [Bol94] and Moats [Moa94]. 

1. Requirements 

As the backbone of the UAV controller, the RTE designed for this research acts like the conductor 
of an orchestra, directing the flow of data and cueing the execution of the various controller functions at the 
correct moment in time. The controller's most basic requirement is to provide positive control of the aircraft. 
This includes analyzing the present stale, comparing the present state with the desired state, and making the 
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necessary adjustments. In order to provide this control, the control software must meet several other criteria 
as well. Specifictilly: 

• The software must he able to receive data from all flight sensors (GPS, INS, non-INS). 

• The softwiire must recognize and store a correct and complete data package from each sensor. 

• The softwiire must recognize and discard corrupted data packages received from any sensor. 

• The software must itlways maintain the most recent data available from each sensor. 

• The softw;ire must provide Kalman filtering of navigation data, selecting the most appropriate 
source for use by the control itlgorithm 

• The software must recognize command input and determine desired aircraft posture and 
position. 

• The softwztre must calculate corrections necessary to correct any deviations from desired 
posture and position. 

• The software must generate PWM signals for servo motors to effect the necessary corrections. 

• The softwtue must be able to tninsmit and receive data through the dataiink as necessary. 

Other requirements are not as obvious, but became apparent during the development of the system. They 
include a predisposition to be written in C language and to be interrupt driven. In addition, the RTE must 
deal effectively with exception^ circumstances, and it must be flexible and clearly written. 



a. The RTE should be written in C language 

Because of the low level prognimming requirements, the project did not fit well with an 
object-oriented paradigm. In addition, aeronautical engineering students developing the control algorithm are 
using a program called Matrix-X which generates modules in C code. To interoperate with these modules, 
and for reasons mentioned in Chapter II, C was chosen its the programming language. 

b. The RTE should be interrupt driven 

As delineated in Chapter II, hard real-time systems are required to meet timing deadlines 
imposed by the outside environment or risk system failure. When the control loop is initiated by a timed 
interrupt, it assures that the system will always execute positive control functions at a uniform interval which 
is easily regulated. This not only frees the processor to do other things when not executing the control loop, 
but also allows the control loop to interrupt slower (by processor standards) processes, such as generating 
servo commtmd pulses or writing to the screen, prohibiting their occurrence from affecting system timing 
deadlines. 



c. The RTE must deal effectively with exceptional or emergency occurrences 

What if the damlink fails or the buffers tire full? What if the CPU gets into an infinite loop 
or comes to a halt? What if the operator wants to reset the system? What if the GPS or 1MU do not deliver 
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a complete message? These or any number of other possible mishaps or exceptions can occur, and the system 
must be able to respond appropriately and reestablish positive control of the aircraft. Any problems with 
system integrity come under the auspices of the RTE. 

d . The RTE must be flexible to evolve with the rest of the system 

The development of the UAV was designed in five phases, as outlined by Reichert [Rei93]. 
As the control of the UAV evolves from remote ground control to full automation, the software must be 
flexible enough to evolve with it. To facilitate this requirement, it should be modular in design; each 
procedure should be self-contained and should perform a specific function. 

e . The RTE must be clearly written to facilitate follow on work 

Just as this is not the first resetirch project on the UAV, it will not be the last; however, 
interoperability mid cohesiveness will still be requirements. The software programs are intended to be 
self-explmiatory through form, logic, and inserted comments. Where they are not, this research document is 
intended to serve as a programmer's manual for till functions of the software. 

2. Definitions 

All preprocessor directives, including compiler token definitions, global variable definitions, and 
procedure prototypes ;tre contained in the lone header file called DEFS.h. An index of all other variable 
names is contained in Appendix B, which may be used as a glossary by subsequent programmers. Special 
complex vmiables are stored in C structures, as described below. 

a. Structures 

Very few structures me used in the control software, as the necessary data types are not 
complicated. The first is struct T OPS, introduced by Twite [Twi94] and fully defined in the header file 
GPSTRUCT.h. This structure is globally maintained and gives access to all possible information obtained 
from the GPS receiver by simple structure-member reference. For example, the control algorithm could 
access the degrees of latitude of the present position by simply using the variable name 
gps, pcs. latitude, degrees. 

The second is a PANDL , which represents a pointer and its length. This is the preferred 
method of passing data contained in buffers of differing length. It allows one structure argument to be passed 
and yet iillow the same procedure to hiindle the various length buffers consistently. 
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3. Conventions 



As a means of slandadization, a set of conventions have been established in the design of the 
control softwiire. Any procedures not p;irt of the RTE, but subsequently added to the controller software 
(hereitlter termed participating procedures) should conform to these conventions. In order to avoid 
contention and interference, the RTE must maintain control over several critical parameters, including 
execution timing, data transfer, memory allocation, and the operation of the hardware, particularly the 
daUtl ink. 



a. The RTE must maintain control over all timing 

This is the defined function of the RTE, yet for it to be effective, participating procedures 
should be of relatively constant execution time. Recursion and loops must be used carefully, and the 
participating procedure should not call smother procedure that should be under the control of the RTE. The 
challenge of programming the RTE is then reduced to a complex scheduling problem among a relatively 
small number of processes which all have concise scope and operating parameters. 

b. The RTE must maintain control over all data 

As a corolkiry to the previous requirement, the RTE also maintains control over all aspects 
of data storage sind transfer. This includes I/O port number definitions, flow control definitions, and actual 
I/O requests including input from the keyboard, output to the screen, or data transfers with the datalink. This 
is crucial to maintain coordinated operation of all controller functions. Any participating procedures must 
refrain from making their own data transfer calls, unless it is the express function of that procedure. Data 
information placed in a buffer is passed using the PANDL structure defined above. 

c. The RTE must maintain control over memory allocation 

In the course of operation, a given procedure may be called many times by the RTE. Memory 
allocation is a relatively slow procedure, and should be minimized and carefully managed. Any procedures 
that allocate memory must cle;ir that memory prior to return to the calling program. It is preferred to have 
the RTE ;dlocate the memory ;md then pass that PANDL to the participating procedure fill the buffer and 
modify the length. 

d. The RTE must maintain control over the hardware 

It is the function of the RTE to direct the execution of the h;irdware. Unless it is their defined 
purpose, participating procedures should not send signals to lntrdware or in any iminner change the operating 
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piiraineters of the hardw;ire established by the RTE. This will preclude the RTE from coming into contention 
with the operation of one of the p;irticipating procedures. 

e. Messages coming from the ground must have a set format 

Because the datalink was only used to transmit information down to the ground in this 
research, this format has not been completely established. The read_datalink() procedure is written to expect 
a special character to denote the sum of the message (presently using '#’), followed by a two byte integer 
representing the length of the message in bytes, followed by the message itself. It is possible to also include 
a one byte action code after the message length to help the RTE determine what action to take with the 
incoming message. Participating procedures that uplink information to the RTE must follow this convention 
for the message to be properly deciphered. 

IL COMPILER CONFIGURATION 

The softwme w;ts developed under Borland C/C++, version 2.0. Invoking this program using the 
command BC, without any Hags, brings the user into an integrated development environment (IDE). The 
IDE, otherwise known its the Programmer's Platform, includes a multi-file editor, multiple overlapping 
windows, an integrated debugger, a built in assembler, and support for in-line assembly of other object 
modules. Pull down menu selections <'tre at the top of the screen, and most are similar to other graphical user 
interlaces. The following compiler configuration parameters are important to ensure that the code will 
compile properly. 

I. Project File 

Using the Project pull down menu gives access to the project file. The project files are kept in the 
C:\borlandc\hin directory ;ind perform two important functions. First, the status of the screen (or desktop) 
and all preferences selected, including compiler options, are stored in the project tile. Then, when the project 
is opened, the screen and all preferences are automatically returned to the settings selected for that project. 
Second, the project conutins a list of files to be compiled at run time. This allows the user to specify other 
files, like header files or separate object modules, to be included in the compilation. As shown in Figure IV- 1 , 
two such files me required for correct compilation of the controller software. 812CL.lib is an object code 
library for the intrinsic functions used to operate the PCL-812 board. MOXA-CL.obj is an object code 
module for the intrinsic functions used to access the PCL-744 board. According to the manufacturer, both 
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bo;trds require that the intrinsic functions he used to access the boards. Experience has confirmed that the 
intrinsic functions are tdso the easiest and most efficient method of accessing the functions of these boards. 



Project: Monitor 



File Name 



Location 



Line Code Data 



Monitor.c 

812CL.lib 

MOXA-CL.obj 



AAControl 

..\..\PCL-812\C 

AAPCLS-802\LIB\C 



946 14788 4209 

n/a n/a n/a 

n/a n/a n/a 



Figure IV-1: Compiler Project Screen 

2. Compiler Options 

The Options pull-down menu gives access to the selected compiler options. Most of these may 
be set to the user’s preference, but several ;tre important and should not be changed. Under Code Generation , 
the huge memory model should be selected and Automatic Far Data should be checked. Because of the 
k 'segment:offset” addressing scheme in the computer, several memory models are available. For each item 
of code or dam, the compiler can either generate explicit segment and offset addresses or can use the offset 
alone within a default segment address. The htrge model generates explicit segment and offset addresses for 
all data items, thus blowing an unlimited amount of code ;md data with only one constraint: no single data 
item c;m exceed 64 Kbytes [BarX9]. This model is shown graphically in Figure IV-2, and is necessary for 
direct memory access and for setting f;ir pointers used in the interrupt service routines (ISRs). 

In the Entry! Exit Code Generation menu, neither Standard Stack Frame or Test Stack Overflow 
should be checked. Because of the heavy use of the stack for ISRs and console functions, like printing to the 
screen, the stack frame should be as large as possible. Additionally, with the Standard Stack Frame option 
turned off, ;uiy function that does not use local variables and has no parameters is compiled with abbreviated 
entry and return codes. This makes the resulting code shorter and faster. The Test Stack Overflow generates 
code to check for stack overdo w at run time. This code is not necessary, and can cause run-time problems in 
the controller. Similarly, under the Linker option, no stack warning should be checked. During interrupts, 
the stack is not where the stack checker expects it to be. Under Optimization options, select optimize for 
speed. Under norimil conditions, the compiler will choose to optimize for size, choosing the smallest code 
sequence possible. With this item toggled, the compiler will choose the fastest sequence for each task. This 
is important since the program does not come close to exceeding the 2.88 Mbytes available on the RAM Disk, 
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but is significantly tiine-constniined. Last, under Directories , the compiler is operating with the Include 
directory set to C:\borlandc\include, the Library directory set to C:\borlandc\lib, and the Output directory set 
to C:\control. 




C. SYSTEM INITIALIZATION 

This section highlights initializations that must be completed before the program can start the flight 
management unit (FMU) sequence to control the UAV. For proper operation, the software program must 
have been compiled in aecordiuiec with the compiler options described above. Then, once the program is 
invoked, the main() procedure is the first code to execute. 
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1. Software Initialization 



In the beginning of the main() procedure, special exit handling routines are set up. The atexit() 
procedure directs the prognun to execute the shut_down() procedure whenever the program is terminating 
from any reason. This is a handy function because the termination point can come anywhere, yet the 
shut_down() procedure will always be executed, assuring that the ISR vectors have been returned to normal, 
the allocated memory has been freed, and the I/O ports have been properly closed. 

The ctrlbrk() procedure establishes a return point in the program in the event of a control-break 
key sequence. It can be seen in the breakjiandler() routine that this is a method for completely restarting the 
program without having to reboot. After the exit handling routines are set up, the global structures needed to 
hold sensor data tire allocated. This includes a struct T_GPS, PANDLs for the IMU and GPS information, 
and data and panim ;trrays for the PCL-812. 

2. Hardware Initialization 

After establishing exception handlers and memory allocation, the main program calls 
initializejiw() . This procedure controls the pmmneters of the hardware that must be set up in software, 
which is necessjiry for three of the luudwme ctirds: the PCL-812 Lab Card, the PCL-744 Serial I/O Card, and 
the PCL-830 Timer/Counter Gird. 

a. PCL-812 

The PCL-812 relies solely on the param array for information concerning its operation. It is 
important that the hardware ;ind softwitre configurations match. Specifically, param[4], IRQ level, must 
match the setting of jumper JP4; param] 7], trigger level, must match the setting of jumper JP1; and 
parum[ 17|, gain code, must match the setting of jumper JP9. Other important parameters are param[5] and 
param [6], the product of which divides the 2 MHz clock to determine the speed of the internal trigger, and 
piirainf 14], 1 15], and [ 16J that set how many A/D conversions will be done and on which analog inputs. With 
the param array established, the initialise _hw() procedure calls PCL-812 function 3 to initialize the hardware 
and PCL-812 function 4 to begin A/D conversions. 

b. PCL-744 

The PCL-744 uses the same library of software functions as the PCLS-802 Serial I/O Card, 
which is not used in this project. The PCLS-802 software has three major parts: first is the complete RS-232 
based software device driver for I/O processing mid control: next are the interface libraries which allow the 
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use of high-level programming languages to control serial communications; and third are application 
programs which allow troubleshooting of the serial communications. All of these interface library procedures 
begin with “sio_” and so are hereafter termed sio functions. Advantech engineers have confirmed that the use 
of these library functions is the only method available for accessing the PCL-744. These sio functions are 
fully described in Chapter 3 of the PCLS-802 PC-ComLIB Manual by Advantech. The initialize_hw() 
procedure uses these sio functions to configure each of the eight serial ports as follows: 

• 9600 baud rate 

• 8 data bits 

• 1 stop bit 

• No parity 

• DTR off 

• RTS off 

• Hjtrdware How control off 

• Software flow control off 

Compiler vjiriables for the bit configurations needed for these settings are found in HEAD-C.h. Companion 
sio functions me used in checkJwdwareO to read the values set for each port. After configuring the ports, 
initialize _hw() opens each port, flushes (he receive and transmit buffers, and sends initialization codes to the 
GPS receiver and the IMU. 

c. PCL-830 

The hist section of initialize_liw() initializes the PCL-830 card. The original software was 
written by Moran [Mor93] for another circuit card that also used AMD9513 System Timing Controller (STC) 
chips, and so it could be ported over with minor modifications. This code is well documented by Merz 
[Mer92]. Each timer is configured as follows: 

• Counter clock source set to FI (1 MHz) 

• 8 bit wide data bus (mandatory for the PCL-830) 

• Bintiry counting on falling edge, counting down repetitively 

• Reload counter from Load or Hold register 

• Disabled data pointer increment (this is controlled by for-loops in software) 

• No gating control 

• Output control set to toggle on terminal count 

This configuration is equivalent to a specialized version of the AMD9513 Mode F. Under this configuration, 
the individual counter is alternatively loaded from its Load ;ind Hold registers. First, the counter loads the 
v:ilue from its Hold register and puts the output high (5 V) upon terminal count (counting down to zero). Then 
the counter loads the value from its Load register ;md toggles the output low (0 V) upon terminal count. The 
value in the Load register creates the desired length of the PWM pulse, which should be between 0.6 ms and 
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2.4 ms. The sum of the Load ;uid Hold registers sets the PWM signal refresh rate, which should not exceed 
10 ms (Dav92J. Notably, this mode differs from Mode C in that the counters are not required to be loaded 
and ;irined manually, except initially. This initial arming is done at the end of initialize_hw(). 

I). INTERRUPTS 

Interrupts c;m come from two different sources: hardware and software. Both hardware and software 
interrupts ;tre decoded by hardwire chips called Peripheral Interrupt Controllers (PICs), and both use the 
interrupt vector table to find the location of the interrupt service routine (ISR), a small program designed to 
address the cause of the interrupt. H;u*dw;ire interrupts typically call the processor’s attention to an external 
event, such as a key stroke or other asynchronous action. Conversely, software interrupts are like 
instructions; they are part of, ;ind therefore synchronous with, the running program. 

The lowest 1 Kbytes of memory is allocated for an interrupt table that can store the four byte 
“segment:offser address for each of 256 ISRs. The correct ISR is located by its number, no matter where it 
is located in memory. The CPU simply has to multiply the interrupt number by 4 (since each segment has 
four bytes) and jump to the address it finds at the resulting offset in segment 0. For example, the address of 
the ISR that serves interrupt 70 is found in segment 0 at tin offset of 70 X 4 = 280 = 1 18h. The interrupt table 
does not contain the ISR code itself, but the address of the beginning of the ISR code. To change the 
execution of an ISR, it is only necessary to clmnge the address in the interrupt table for the desired interrupt. 
Upon occurrence of tin interrupt, the CPU will place the value of the program counter and all internal registers 
on the stack for future reference. Then it will look up and jump to the address of the ISR. Upon completing 
execution of the ISR, the CPU then retrieves the information it had placed on the stack and resumes normal 
operation [Nor85|. 

The PIC is the chip that tninsfates external interrupt request signals (IRQs) into hardware interrupts, 
allowing extern^ devices to generate interrupts. The microprocessor itself has only two interrupt lines: one 
lor maskable interrupts and one for non-maskable interrupts. Maskable interrupts are those that can be 
disabled or enabled in softw;ire. The PIC assigns priorities to its eight interrupt lines, with line 0 programmed 
for the highest priority by default. When one of the lines is activated, the PIC blocks all IRQs of equal or 
lower priority. It continues to block these IRQs until it receives an end-of-interrupt (EOl) code from the 
processor. The processor communicates with the PIC at the microcode level. When its maskable interrupt 
line goes high and interrupts :ue enabled, it queries the PIC which is the highest pending IRQ and then jumps 
to the associated interrupt vector. The CPU c;trd has two 8259 A PICs. The output line of the secondary PIC 
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is attached to IRQ 2 of the primary PIC, and the output line of the primary PIC is connected to the processor. 
This allows 16 different IRQ signals to he recognized by the processor. When IRQ 8 or higher is generated, 
the processor queries the PICs and finds IRQ 0 through IRQ 7 of the secondary PIC is cascaded through IRQ 
2 of the primary PIC [Rie93]. 

1. Generating Software Interrupts 

As discussed in Chapter 11, the cadence of the entire control loop is built around the periodic 
occurrence of a soflwttre interrupt. Because the CPU will immediately jump to the ISR when interrupted, 
placing the beginning address of the control loop prognim in the interrupt table, and generating a periodic 
interrupt to jump there, will guarantee a consistent frequency of control loop execution. For the UAV, the 
entity that executes the control loop is called the Flight Management Unit (FMU). Within the start_fmu() 
procedure, the ISR for the RTC interrupt (7()h) is replaced with a pointer to the control loop procedure 
new_vector(). Start_fmu() then proceeds to generate a periodic interrupt, as described below. 

Every computer Ikls some version of a Programmable Interval Timer (PIT). Intel 80X86 
processors usmtlly use a 8253 or 8254 PIT that hits three independently programmable 16 bit counters that 
ciui be configured in any of six counter modes. On the CPU card, one of these counters is used to periodically 
refresh the DRAM; one is used to generate tones for the speaker. The third timer is used to generate an 
interrupt 8 (IRQ 0) at 18.2 Hz used to adjust the current time and date in the system BIOS area. It seemed 
like a simple process to change the frequency of this interrupt and “hook” it for the FMU; however, this led 
to problems. Because 1RQ0 is the highest priority, all other computer functions, such as serial 
communications, disk operations, ;uid keyboard activations, were all blocked out by the PICs. In addition, 
some parts of MS-DOS that require periodic service hook this interrupt, and these functions could be 
adversely affected by changing the frequency of the interrupt. Most significantly, the engineers at Advantech 
confirmed that the 8254 functions on the CPU ettrd are p;trt of an “integrated chip set” and could not be 
accessed independently. For these reasons, another timer had to be used. A timer on the PCL-830 could be 
used, but this was discounted because it was on another card and would generate unnecessary data traffic on 
the backplane bus. Fortunately, there is ^mother timer available on the CPU card that generates interrupts — 
one that is not widely documented, but is available on the hardware. It is called the Real-Time Clock. 
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2. The Real-Time Clock 



The real-time clock (RTC) is p;irt of the Motorola MC146818A CMOS chip shared by the system 
BIOS. As compiired to the 8254 PIT, it has several disadvantages: 

• The RTC is less flexible; it handles only 15 possible interrupt frequencies between 2 Hz and 
32767 Hz. 

• The default ISR switches off the RTC interrupt after a time-out expires. 

• The RTC and IRQ 8 ;ire not well documented. Most of this information was gleaned from 
online sources from the Internet. 

Still, the RTC is perfect for this* research application because it avoids all of the problems listed 
above for the 8254 chip: 

• The RTC allows the higher priority keyboard and I/O interrupts to proceed normally. 

• The RTC is not polluted with side effects. 

• The RTC is available for use on the hardware being used. 

Because the RTC exists outside of the normal address space, it cannot contain directly executable 
code. It is communicated with through I/O ports 70h and 7 1 h. Port 70h is the index register and port 7 lh is 
the data register, as defined in DEFS.h. All internal registers of the RTC are accessed by setting an index at 
port 70h and reading from or writing to port 71h. The output from the RTC is in hexadecimal. Figure IV-3 
detziils the CMOS memory allocation. The ten clock data registers are not used in this research, although it 
is envisioned that the system clock will be updated from the GPS time data in the future. In order to use the 
RTC to generate periodic interrupts, only the four status registers are used. 

There are a few caveats when programming the RTC. First, the data register must always be read 
from or written to <ifter writing to the index register. Also, there should not be a long delay between writing 
to the index register and reading from or writing to the data register. Waiting too long between the two 
operations can cause a malfunction of the CMOS chip [Dun86J. Interrupts must be disabled while 
programming the RTC. The non-maskable interrupt (NMI) must also be disabled. Since the chip is 
non-volatile, it continues to work even in the event of a system reboot caused by a NMI. The system reads 
viud parameters from the chip, such as memory size and configuration. Malfunction of the RTC chip is to be 
avoided at ;l1I costs. Therefore, it is sid’est to toggle the NMI off by toggling bit 7 of the index register when 
selecting the status register to use. The following describes how the status registers are utilized. 
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The first 14 bytes of the MC146818 chip consist of ten read/write data registers 


and four status registers, two which are read/write and two which are read only. 


The format of the 10 data registers is: 


OOh 


Seconds 


(BCD 00-59, Hex 00-3B) Note: Bit 7 is read only 


Olh 


Second Alarm 


(BCD 00-59, Hex 00-3B) 


02h 


Minutes 


(BCD 00-59, Hex 00-3B) 


03h 


Minute Alarm 


(BCD 00-59, Hex 00-3B) 


04h 


Hours 


(24 Hr. Mode: BCD 00-23, Hex 00-17) 






(12 Hr. AM: BCD 01-12, Hex 01-0C) 






(12 Hr. PM: BCD 81-92, Hex 81-8C) 


05h 


Hour Alarm 


(Same as Hours, above) 


06h 


Day of Week 


(01-07, Sunday = 01) 


07h 


Date of Month 


(BCD 01-31, Hex 01-1 F) 


08h 


Month 


(BCD 01-12, Hex 01-1C) 


09 h 


Year 


(BCD 00-99, Hex 00-63) 


The format of the four status reaisters is: 


OAh 


Status Register A 


(read/write) 




Bit 7 (Read Only) 


1 = update cycle in progress, data undefined 




Bits 6, 5, 4 


22 stage divider of 32.768 KHz time base 




Bits 3 - 0 


Rate selection bits for interrupt 


OBh 


Status Register B 


(read/write) 




Bit 7 


Cycle update: 0 = disabled, 1 = enabled 




Bit 6 


Periodic interrupt: 0 = disabled, 1 = enabled 




Bit 5 


Alarm interrupt: 0 = disabled, 1 = enabled 




Bit 4 


Update-ended interrupt: 0 = disabled, 1 = enabled 




Bit 3 


Square wave output: 0 = disabled, 1 = enabled 




Bit 2 


Clock data mode: 0 = BCD, 1 = Binary 




Bit 1 


24/12 Hour Selection: 0 = 12, 1 = 24 




Bit 0 


Daylight Savings Time: 0 = disabled, 1 = enabled 


OCh 


Status Register C 


(read only) 




Bit 7 


Interrupt request flag: 1 if any of bits 6 - 4 are 1 and 






appropriate enables in Reg. B set to 1. Generates IRQ8. 




Bit 6 


Periodic interrupt flag 




Bit 5 


Alarm interrupt flag 




Bit 4 


Update-ended interrupt flag 




Bits 3 - 0 


Not Used 


ODh 


Status Register D 


(read only) 




Bit 7 


Valid RAM: 0 = dead battery or disconnected, 1 = good 




Bits 6 - 0 


Not Used 



Figure I V-3: Organization of CMOS Memory 
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Status register A is used to seleet an interrupt rate. The basic oscillator frequency is 32,768 Hz, 
set in bits 4 - 6. The lower four bits (0-3) of status register A select a divider for this oscillator. The resulting 
frequency is used to generate an interrupt 7()h, or IRQ 8. The system initializes these bits to 01 10 binary, 
which selects a 1,024 Hz frequency according to the following formula: 

Inter ruptFrequency = OscillalorF requency » {rate- 1 ) 



which can be simplified as 



Interrupt Frequency 



65536 

2 rate 



Table IV- 1 lists the subset of interrupt frequencies likely to be used for the UAV controller. These 
frequencies tire generated when the corresponding rate is specified in DEFS.h. Presently, the controller is 
executing a 32 Hz control cycle. The fastest frequency possible is 8 KHz using a rate of 3. When using a rate 
of either 2 or 1 , the counter rolls over, resulting in the same frequencies as rates 9 and 8 respectively. 



TABLE IV- 1 : CMOS Interrupt Frequencies 



Rate 


Frequency 


10(0 Ah) 


64 Hz 


11 (OBh) 


32 Hz 


12 (OCh) 


16 Hz 


13 (ODh) 


8 Hz 


14 (OEh) 


4 Hz 


15 (OFh) 


2 Hz 



Status register B contains a number of flags. To enable the chip to generate periodic interrupts, 
bit 6 must be set. Status register C is read only and also contains a number of flags. When several interrupts 
of the RTC are connected to IRQ 8, these flags make it possible to detect which interrupt caused the IRQ 8: 
periodic interrupt, alarm interrupt, or update ended interrupt. Lastly, the PIC status register must be 
unmasked. Each PIC has 8 bit mask that disables selected IRQs. The American Megatrands BIOS 
disables IRQ 8 at startup. By clearing bit 0 of the secondary (slave) PIC, IRQ 8 is enabled. 

These actions generate a periodic interrupt, but only a single one. Unless status register C is read, 
IRQ 8 will not be generated again. This means status register C is read inside the ISR, even though its content 
is not important for this application. The PICs also come into play here. Since the PIC blocks all IRQs of 
equal or lower priority upon the occurrence of an interrupt, the next periodic interrupt cannot be generated 
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until the PICs receive an end-of-interrupt (E01) code from the processor. This is accomplished by directly 
outporting EOI (value of 20h) to I/O addresses 20h and AOh, the addresses of the master and slave PICs 
respectively. These repetitive actions must he done on every occurrence of the periodic interrupt and so are 
accomplished inside the ISR in a subroutine called reset_int(). 

Common practice when writing ISRs is to jump to the old ISR after executing the new one, but 
because the old ISR halts the periodic interrupt, this method was not used. Without the old ISR, some 
interrupt 15h BIOS functions will fail; however this did not manifest any problems in the present 
configuration. If necessary to alleviate this in the future, store at address 0040:009b a double word value that 
is at least 976 and jump to the old ISR. The default ISR subtracts 976 from the value at that address and halts 
the RTC periodic interrupt if the result is less than zero. 976 is derived as the number of microseconds that 
elapse between two invocations of interrupt 70h if the RTC is counting at its default frequency of 1024 Hz. 
The default ISR also issues an interrupt 4Ah when timed out [Bro92]. 

In addition to resetting the interrupts, the ISR, new_vector(), also increments a count of the 
number of cycles and calls the actual control loop procedure, execute_cycle(). It is within this control cycle 
that id! of the I/O and flight control operations takes place. 

E. THE CONTROL CYCLE 

The control cycle is embodied in the cxecule_cycle() procedure. It is called by new_vector() upon each 
occurrence of the periodic interrupt. During the control cycle, the controller first retrieves the information it 
needs to determine the state of the aircraft by invoking each of four I/O device drivers; next, it calculates any 
corrective actions necessttry in the f1ight_control() procedure; and finally, it generates the PWM signals 
necessity for the servo motors to effect those corrective actions in the cmd_to_servos() procedure. It is 
important to note that not till of these procedures are called during each cycle. Using modulo division of the 
cycle count, it is possible to regulate the interval and period of the various functions. The objective is to keep 
the task load for each control cycle relatively steady. The actual timing of these functions is dependent on 
the frequency of the interrupt. For example, the IMU is read every fourth cycle for control purposes, but is 
only downlinked to the ground twice each second. This programming strategy keeps the RTE flexible and 
the timing prmuneicrs easily modified. Each of these functions will be examined in detail. 

1. I/O Device Drivers 

Four I/O device drivers exist within execute_cycle() to take care of the data transfer and storage 
from the four priimtry sources of data for the FMU. They a re read_imu(), read_gps(), read_atod(), and 
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xmit_to_gnd(). Each of these procedures reads one complete data message from their appointed interface and 
places that message in a pre-established globtd data buffer. 

As described in Chapter 111, the complete data message from the IMU is 38 bytes long and 
terminates with a carriage return. The global buffer, imu_buf->ptr, has 100 bytes allocated in the main 
program. Because of this buffer restriciion, read_imu() reads the length of the queue and truncates it to 100 
bytes. It then determines if the data in the receive buffer constitutes a partial or full message. If a partial 
message exists, it reads it away before reading in the next full message. Last, it confirms whether the message 
read was a complete 38 byte message and sets a flag accordingly. 

Read_gps() works much the s:une way, except that a full position message is 68 bytes and 
terminates with a carriage return and a line feed. A 500 byte buffer is allocated in main(). This procedure 
pares down the receive buffer until the buffer size constitutes at least one full message and at most one full 
message plus a ptirtial message. If a p;irtial message exists, it reads it away and then reads in the next full 
message. It also confirms whether the message read wjls a complete 68 byte message and sets a flag 
accordingly. 

The A/D process on the PCL-812 card was initiated in the initialize_hw() procedure. To read the 
data generated into the data array, readjitodO needs only to call PCL-812 function 5, and the data is read in 
automatically. Since the data received is a 12 bit digital conversion scalar value, determining the actual 
analog voltages requires a ctilculation similar to that done in the show_air_data() procedure. 

Depending on the mission and the mode of flight, varying amounts of data will be required to be 
transmitted to, and received from, the ground station through the datalink. This data transfer is done by the 
read_datalink() and xmit_to_gnd() procedures. Read_daudink() was written for functional completeness, but 
is not utilized in this research. Based on the last convention in Section A.3 of this chapter, read_datalink() 
will look for the beginning-of-message cluuacter, then read the message length, convert the length to an 
integer, and use the length given to read in the appropriate number of bytes constituting the message. If a 
message is read, it is stored in the global bufler dl_buf, and a flag is set accordingly. 

The xmit_to_gnd() procedure has the adv;tntage that the length of the message to be transmitted 
is known from the PANDL passed in. The procedure uses the sio_putb function to transfer the data to the 
data! ink's transmit buffer. Experimentation has shown that the sio_write function works equivalently well. 
The only exception that must be considered is a lull transmit buffer. This situation should never occur under 
normal operating circumstances: however, in the event that it does occur, the buffer is flushed under the 
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assumption that the data presently attempting to be sent is the most recent and therefore more valuable than 
the old data that was clogging the buffer. 

2. Flight Control 

Now that the controller hits all the information it needs from the various I/O drivers, all that 
remains is to calculate the control inputs necessary to fly the airplane and move the servo motors 
appropriately. The flight_control() procedure in this research is only a placeholder for the control algorithm 
module being developed in the Aeronautical Engineering Department. Eventually, this procedure will 
provide the Kiilman Altering options for choosing the appropriate navigation data from what is available and, 
using this data, will calculate integer control cointnands for the throttle and for each of the standard 
three-dimensiontd control surfaces: aileron, elevator, and rudder. These control surface commands are then 
passed to the cmd_to_servos() procedure, which tntnslates the three-dimensional control surface commands 
into individual vane comiminds. The integer command expected by cmd_to_servos() presently represents the 
number of degrees of deflection, but it could be changed to any agreed upon standard between flight_control 
and cmd_to_servos. Cmd_to_servos() then sends the appropriate signals to the PCL-830 to generate the 
precise PWM signal needed by each vane servo. This concludes the control loop segment of the program and 
meets till of the requirements for positive control outlined above. The RTE now returns to the point of 
execution prior to being interrupted and continues its normal activity until the occurrence of the next periodic 
interrupt. 

F. USER SERVICES 

When not executing the control loop, the computer is primarily available for user-oriented services. 
These services include a gamut of small procedures designed to interact with the system user and provide 
information. Because the system runs on interrupts, the control loop described above appears to be running 
in the background, while these user services utilize the screen and keyboard and appear to run in the 
foreground. The initial and primary interface with the user is the menu() procedure. Menu() presents a 
command line, prompting for user input. A new user may respond with a question mark, which yields a menu 
of possible choices, as shown in Figure 1V-4. The first three choices, check hardware, start flight 
management unit, and quit flight management unit, have been described above. The remaining choices are 
described below. 
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Archytas Monitor Program 
Command ('?’ for help): ? 

The following are valid commands: 



(c) heck hardware 

(s) tart flight management unit 

(q) uit flight management unit 
(f)light data menu 
(m)emory contents display 

(r) egister contents display 
(i)nterrupt vector display 

(d) os command 

(t) erminate program 

Command (“?’ for help): 



Figure IV-4: Main Menu Screen 

ChoosingyZ/g/tf data menu invokes the show_flight_data() procedure, which presents a secondary menu 
as shown in Figure I V-5. This menu enables the user to inspect and verify the contents of the global buffers 
containing the llight data gathered during the control loop from each of the I/O device drivers. This includes 
ASCII representations of the untranslated GPS message ;ind the output from the IMU, the hexadecimal values 
and corresponding voltages of all A/D analog sources, and the present positions of all servos. These values 
represent the instantaneous buffer contents at the moment in time they are retrieved. If the FMU is running, 
the buffer contents may change immediately after being read. 



Display which data? 



(g)ps position 
(i)mu data 
(a)ir data 

(s)ervo positions 

Choice: 



Figure I V-5: Flight Data Menu Screen 



The memory come ms display, register coni ems display, and interrupt vector display main menu choices 
enable the user to inspect the contents of :my block of memory, the contents of all storage and segment 
registers of the processor, ;tnd the I SR address stored in the interrupt table for any given interrupt respectively. 
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Similar to the utility of a debugger, these procedures were used primarily during the development of this 
program and ;ue included for future debugging needs. When programming at such a low level, interacting 
with individual memory locations and I/O ports, it is often necessary to have the utility of these procedures. 

Lastly, the dos command menu choice invokes an MS-DOS shell that the user can work in while the 
FMU is still running. All basic DOS functions, such as copying files, directory listings, and invoking small 
programs lire available, as long as the intended task does not require BIOS interrupts 8 lh or 83h. Terminating 
the program will also yield a DOS prompt, but only after the program completes its shutdown sequence. 

One other secondary menu is available to the user, although it is not listed in the main menu. It is 
invoked by the Ctrl-Break or Ctti-C key sequence. Both of these are standard key sequences used when the 
user wants to terminate what is executing. In this case, the break_handler() procedure is invokes and a menu 
similar to Figure 1V-6 is displayed. 



Why did you break? 

(c)old reboot machine 
(w)arm reboot machine 
(r)estart program (reinitialize hardware) 
(g)o back to main menu 
(t)erminate program 

Choice: 



Figure IV-6: Break Handler Menu Screen 

The most drastic response to this prompt is a cold boot . This is similar to the system initialization done 
when first powering up the computer, including ;dl diagnostic and memory checking sequences. A warm boot 
is similar to the Ctrl-Alt-Del key sequence and causes the computer to reboot without the diagnostic and 
memory checking sequences. This makes it slightly Lister and less disruptive than a cold boot. Both of these 
options invoke the bootstrapO procedure, passing in the chosen parameter of cold or warm. Because disk 
caching is used, bootstrapO first Hushes the caches to insure that no information is lost and reboots the 
computer. If the computer is operating correctly, the user may elect to re-initialize only the controller 
luirdwarc This restart program option causes the computer to execute the hardware shutdown sequence and 
then stiul the program again from just alter the buffer allocation in main(). Other choices allow the user to 
return to the main menu or terminate the program. 
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CHAITER SUMMARY 



This chapter gives a dehuled description of the software program written to function as the control 
sollwme for the UAV. The reader should understand the full scope of the endeavor, including the 
requirements and guidelines under which it was written, and the interoperability with the hardware, including 
those sub-systems developed previously by other students. This chapter serves as a programmer’s manual, 
to aid the understanding of the code shown in Appendix A, as well as to set conventions and guidelines for 
subsequent code to follow from other work on the UAV project. The operation of the Real-Time Clock chip, 
in p;irticul;ir, is not documented elsewhere, mid is therefore completely detailed in this chapter. 
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V. CONCLUSIONS 



The goal of this resetirch wits to create a functional central controller for an UAV. This controller is 
envisioned to integrate vtirious subsystems designed by other students as part of an overall, interdisciplinary 
development project. It represents the airborne half of a full UAV control system that is planned to evolve 
from remote ground controlled flight to fully autonomous flight in five phases of development [Rei93]. 

A. ACCOMPLISHMENTS 

From the general goal to create an UAV controller, specific operational requirements were derived. 
From these operational requirements, system hardware was selected and design parameters were codified. In 
the course of the design and synthesis of the controller, several significant milestones were achieved: 

• The system hardwire was dissembled and configured for proper operation. 

• A method for generating periodic interrupts was determined and successfully implemented. 

• Multi-path seridil I/O was achieved using the PCL-744 card. 

• Datalink subsystems were successfully integrated. 

• Air data and navigation subsystems were successfully integrated. 

• Servo control subsystems were successfully integrated. 

• The RTE was designed mid implemented to interrelate and coordinate all subsystems. 

• Communication ;ind programming standards were developed. 

• Fault tolerant provisions were made to bolster system reliability. 

• User interfaces were designed and implemented. 

The UAV controller was designed to be as simple as possible, given the hardware on hand and the 
anticipated task load. A real-time executive (RTE) program, initiated by timed interrupts at various intervals, 
Cciils appropriate task modules, mid repeats this process indefinitely. The use of interrupts enabled the 
processor to keep busy during slow (by processor standards) processes, such as generating servo command 
pulses. Under this configuration, the challenge of programming the RTE was then reduced to a complex 
scheduling problem mnong a relatively smtill number of processes which all have concise scope, known 
parameters, and demonstrated cluiracteristics. The only immutable programming requirement was to arrange 
the process schedule of the RTE such that a ctdled process can complete execution prior to the initiation of 
another process, mid so that the resources of interrupted processes are not needed by the interrupting process. 

This research dentils the inter-relations of the design criteria used for this controller, to give the reader 
a better understanding of the ovenill system. From this understanding, present design decisions become 
apparent, and future development is facilitated. The future development described below is recommended to 
develop a more effective and efficient controller design. 
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B. RECOMMENDATIONS 



In the course of development, it became evident that several improvements would be necessary for the 
final implementation of the system. These included standardization of the command structure and 
improvements in data conversion ;ind transfer, in addition to some general system modifications. Also, other 
subsystems with which the controller must interact, namely the aeronautical control module, were not 
completed as of this writing. These meas me recommended for future research and development and are 
briefly delineated below. 

1. Command and Control Structure 

The basic operation of the controller is to determine the state of the aircraft, compare that state to 
a state commanded by the pilot, whether that pilot is a human or the controller executing a set of 
preprogrammed waypoints. Since the control module has not been completed, there is no standard command 
syntax in place. Neither is there a structure for communicating these commands to and from the control 
module. For this rcsetirch, a temponu y procedure mimed flight_control() was written which simply generated 
vane commands in degrees. A future control module should have the capability to read the necessary flight 
data from the globed registers, determine the commanded state , and generate control vane angles compatible 
with the cmd _to_servos() routine. It is this middle function that needs to be carefully defined. 

The control module is expected to output these commands for each of the standard three- 
dimensiomd control surfaces: tiileron, elevator, ;tnd rudder. It is presently the responsibility of the 

cmd_to_servos( ) procedure to translate these commands into appropriate coordinated commands for the eight 
control vmies phuined for installation on the Archyuis (Sto93], This translation is currently incomplete, 
especially considering that the translation ptiraineters must change as the aircraft transitions from vertical to 
horizontal flight. This ;irea requires additional study unless this translation process is absorbed into a control 
module that incorporates both the llight_control() and cmd_to_servos() functions. 

2. Data (Generation and Conversion 

Outside of the control algorithm, the controller's main function is to gather and disseminate 
necessary data to appropriate functions. The faster this data c;w be generated, the better the controller can 
perform. Several factors a re impeding optimum perfonmince, as described below. 

First, the direct memory access (DMA) form of data tninsfer should be used where possible. This 
would preclude the wjiste of processor resources to perform memory to memory copying of data. Several 



accessory hoards, specifically the PCL-744 serial c;ird and the PCL-812 lab card advertise a DMA capability. 
This utility was attempted, hut never successfully implemented during this research. 

Second, the serial ports can transfer data more quickly. The serial card was set up at 9600 bps to 
match with other subsystems that had been designed to operate with a standard RS-232 serial port, which 
normally operate at that speed. The ports of the PCL-744, however, can be configured as high as 38400 bps 
[PCL-744 Manual, p. 16]. Each port should be optimized separately, since some of the connected 
subsystems, like the datalink, can be configured to run at variable speeds, while other subsystems, like the 
GPS ;uul the 1MU run only at 9600 bps. 

Third, the 1MU is too slow. As explained in Chapter III, the fastest possible message frequency 
would be 3 1 .5 Hz. Einpiric;il data has shown the actual message frequency to be closer to 20 Hz. To have 
new IMU data lor every control cycle requires slowing the cycle or increasing the output rate of the IMU. 
Watson Industries does offer v;irious options which can increase the speed of the IMU, and these options 
should be explored. 

Fourth, the speed of the datalink is too slow. As shown in Chapter III, the data transfer 
requirements for remote controlled operation from the ground is above the capacity of the datalink. This will 
become less of a factor as the UA V development progresses towards autonomous flight, but it will always be 
exacerbated by increasing the link overhead as propagation quality deteriorates. Field experimentation will 
show which data is more crucial to control and which data could be sent less frequently. Overall, for positive 
remote control, no more tlmn 100 msec can elapse between pilot command input and the associated 
movement of the control surfaces |Kain93|. In the early stages of development, the datalink is the weakest 
and yel most important link in the control process. 

3. General System Modifications 

Because the datalink proved to be so unreliable, user menu selections were entered directly from 
the keyboard. When the keyboard is removed to place the controller in the aircraft, these menu programs must 
execute through the datalink. Fortunately, because of the case statements used to execute menu choices, the 
user interface programs require only minor changes to read user input from the datalink, rather than the 
console keyboard. 

Second, the GPS routines need to be fully implemented. The procedure read_gps() was written in 
place of Twite's procedure Slave_gps(), which was not fully completed. It is Twite’s program that decodes 
the data shewn from the GPS and places the navigation in a global structure, as discussed in Chapter IV. This 
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convenient access to GPS data will not he available until Twite’s software is completely implemented. This 
includes the potential for accessing GPS data other th;tn the position change status message by uplinking 
commands to the GPS receiver through the PANDL gps->in [Twi94, p. 125]. 

Third, the 25 pin serial connectors on the PCL-744 octopus cable are much too heavy and bulky 
for actual implementation. For the RS-232 connections, only eight wires have the potential of carrying 
signals ;ind, because How control is not used, only three wires are actually used. During actual 
implementation, it is recommended that customized cables be used. 

Last, a multi-tasking or multiple processor CPU board should be investigated. Even without the 
processing-intensive control algorithm, this controller is extremely constrained by real-time deadlines. The 
addition of other processing requirements could force the system to be run at an unacceptably slow interrupt 
interval. Although upgrading to a faster CPU would ease the problem somewhat, a multi-tasking or 
segregated multipie processor environment should produce a better solution with higher flexibility and 
greater throughput. 

C. SUMMARY 

Through this research, the goal of designing and building an UAV controller has been successfully 
completed. The resulting aggregation of h;irdware and software represents a functional shell to which 
improvements can be made, and into which other subsystems, developed in the future, may be added. From 
the initial priimtry research question, down to the final working implementation, this research quantifies the 
system mandates and documents the conceived solutions. This controller represents a proof-of-concept for 
unmanned control of air vehicles, and one that, with the addition of a suitable control module, is ready to fly. 
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APPENDIX A: REAL TIME EXECUTIVE SOURCE CODE 



y**************** ************* J)EJT5 PJ ********************************** 

PROGRAM INITIALIZATION 

# * * * * * * * * * % * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * a|c * * * * * * * * J 

/* Note: MOXA-CL.obi and 812CL.lib must be linked into executable file */ 

# include <stdio.h> 

# include <stdlib.h> 

# include <conio.h> /* For clrscr and cprint */ 

# include <alloc.h> /* For coreleft and malloc */ 

# include <dos.h> /* For DOS and BIOS interrupts */ 

# include <setjmp.h> /* For ctrl-break handler */ 

#include “c:\pcls-802\lib\c\head-c.h” /* For PCL-744 definitions */ 

y* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 

VARIABLE DEFINITIONS 

**************************************************************** **********y 



# define TRUE 1 

# define FALSE 0 



/* Used for RTC Timer */ 

# define RTCJNT 0x70 

# define RTC JNDEX 0x70 

# define RTC_DATA 0x71 

# define REG_A OxOA 

# define REG_B OxOB 

# define REG_C OxOC 

# define REG_D OxOD 

# define INT_FLAG 0x40 

# define NMI.FLAG 0x80 

# define RATE.SET OxOB 

# define RATE 32 

# define PIC.STATUS OxAl 



/* RTC fires interrupt 70h *1 
/* RTC Index Register I/O Address */ 
/* RTC Data Register DO Address */ 



/* Periodic Interrupt Flag is bit 3 */ 
/* Non-maskable Interrupt Flag bit 4 */ 
/* Used to set control cycles per sec: */ 
/* 32768 « (RATE_SET - 1) */ 



/* Definitions for PCL-744 Serial I/O */ 
#define IMUPORT 3 

#define SGPS.PORT 4 

#define DLPORT 5 

#define MGPS_PORT 10 
#define CR OxOD 

#define LF OxOA 

#define IOMODE (BIT_8 I P_NONE I 
#define MODMODE 0x00 
#define HWMODE 0x00 



/* Port number from IMU */ 
/* Port number for Slave GPS Rcvr */ 
/* Port number to Data Link */ 
/* Port number for Master GPS Rcvr */ 
/* Carriage Return is ASCII 13h */ 
/* Line Feed is ASCII lOh */ 
STOP.l) /* 8-N-l (p. 12) */ 

/* DTR and RTS oflf(p.26) */ 
/* HW and SW flow Ctrl off (p.33) */ 



/* Definitions for GPS routines are in GPSDEFIN.H. Each GPS module 
contains its own prototypes, included in the file below: */ 



#include “c:\borlandc\twitefin\gpsfun.h” 
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/* DEFS.h, Page 2 */ 

J** **************************************** ******************************* 

SUBROUTINE PROTOTYPES FOR MAIN PROGRAM (Table of Contents) 
*******************************************************************^******/ 



/* void main(void); 


/* Page 2 */ 


void menu(void); 


/* Page 3*/ 


void initialize_hw(void); 


/* Page 5 */ 


void check_hardware(void); 


/* Page 8 */ 


void start_fmu(void); 


/* Page 10 */ 


void quit_fmu(void); 


/* Page 12 */ 


unsigned char ReadRTC(unsigned char reg); 


/* Page 13 */ 


void SetRTC(unsigned char reg, unsigned char value); 


/* Page 13 */ 


/* void interrupt new_vector(void); 


/* Page 13 */ 


void resetjnt(void); 


/* Page 13 */ 


void execute_cycle(void); 


/* Page 14 */ 


int read_imu(PANDL *buffer); 


/* Page 15 */ 


int read_gps(PANDL *buffer); 


/* Page 15 */ 


void read_atod(void); 


/* Page 16 */ 


void xmit_to_gnd(PANDL *buffer); 


/* Page 16 */ 


int read_datalink(PANDL *buffer); 


/* Page 16 */ 


void flight_control(int *thr, int *ail, int *elev, int *rud); 


/* Page 17 */ 


void cmd_to_servos(int, int, int, int); 


/* Page 18 */ 


void show_flight_data(void); 


/* Page 19 */ 


void show_imu(void); 


/* Page 19 */ 


void show_gps_posit(void); 


/* Page 20 */ 


void show_air_data(void); 


/* Page 20 */ 


void show_servo_posit(void); 


/* Page 20 */ 


void close_ports(void); 


/* Page 21 */ 


void shut_down(void); 


/* Page 21 */ 


void int_vector(void); 


/* Page 22 */ 


void mem_dump(void); 


/* Page 22 */ 


void show_regs(void); 


/* Page 22 */ 


void bit_print(unsigned int v); 


/* Page 23 */ 


void dos_cmd(void); 


/* Page 23 */ 


int break_handler(void); 


/* Page 24 */ 


void bootstrap(int input); 


/* Page 25 */ 



/* Variables for Serial I/O */ 
struct T_GPS *gps; 

PANDL *imu_buf, *gps_buf, *gps_print, *dl_bvzf'; 



/* Y a r i abl.es for Ato D */ 

extern pcl812(int, unsigned int *); 
unsigned int param[60]; 
unsigned int data[20]; 
unsigned int far *dat; 

/* V ari ablgsJflr, C . P . W t e.r/T i mgr */ 
int datreg = 0x210; 
int conreg = 0x211; 



/* PCL-812 parameter array */ 
/* Conversion data buffer */ 



/* Ctr/timer board, base address */ 
/* Ctr/timer board, base addr + 1 */ 
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ysf:*5f:j|':if:;+:if:;t:*:+:;+:**:+::+:jjcj)c******************************************************** 

Archytas Real-Time Executive Program (Page 1) 



Author: LT Peter M. Hoffman 

Written: 1 October 1993 

Revised: 1 June 1994 

Compiler: Borland C++ 2.0 



This RTE program provides the basis of the controller for the Archytas 
Unmanned Air Vehicle. Modifications to the flight_control() and 
cmd_to_servos() procedures could adapt this controller to any UAV 
using the same data path. 



This controller is the center of a multi-dimensional inter- 
disciplinary project collaborated by a number of students from 
various departments of the Naval Postgraduate School, Monterey, CA. 



Please see Thesis Document for complete details and explanation. 
*************************************************************************/ 



# include “c:\control\defs.h” /* All definitions and prototypes */ 

int cyclecount = 0, vane_step = 0; 

int thr_cmd, ail_cmd, elev_cmd, rud_cmd; 

void interrupt new_vector(void); 

void interrupt (*old_vector)(); 

int fmu_start_flag = FALSE; 

jmp_buf cbreak_rtn; 
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/* RTE, Page 2 */ 



void main(void) 



The main program initializes the system, then calls menuQ to 
interface with the user for further actions. 






/* Set up special exit handling routines */ 
a te xi t( sh ut_d o wn ); 
ctrlbrk(break_h an d 1 er) ; 

/* Set up structures to hold data */ 
gps = malloc( sizeofl struct T_GPS)); 
imujbuf = malloc( sizeofl PANDL )); 
imu_buf->ptr = callocl 100, sizeofl char )); 
gps_buf = mallocl sizeofl PANDL )); 
gps_buf->ptr = callocl 500, sizeofl char )); 
dljbuf = mallocl sizeofl PANDL )); 
dl_buf->ptr = callocl 100, sizeofl char )); 

clrscrO; 

/* Set up control-break resume point */ 

iflsetjmp(cbreak_rtn) != 0) (clrscrO; printfTXnRestarting Program. ..”);) 

/* Be gin user interface */ 
printfl“\t\tArchytas Monitor Program”); 
printfl“\n\nlnitializing Hardware...”); 
initialize_hw(); 
menul); 

I /* End Main */ 
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/* RTE, Page 3 */ 



void menu(void) 



This procedure interfaces with the user, querying for the desired 
response and invoking the appropriate routine. 






char ch; 



while(l) { 



printfT‘\n\nCommand (*?’ for help): “); 
scanfl“%s”, &ch); 
switch (ch) ( 
case V: 

check_hardware(); 
break; 
case 's’: 

start_fmu(); 
break; 
case 'q’: 

quit_fmu(); 
break; 
case T: 

sh o w_Jligh t_d ata( ) ; 
break; 
case ‘m’: 

mem_dump(); 
break; 
case V: 

show_regs(); 
break; 
case T: 

int_vector(); 
break; 
case ‘d’: 

dos_cmd(); 

break; 



/* Check Hardware */ 
/* Start FMU */ 
/* Quit FMU */ 
/* Flight Data */ 
/* Memory Dump */ 
/* Display Registers */ 
/* Interrupt Vector */ 
/* DOS command */ 



case *?*: /* List Alternatives */ 

printfl“\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n”, 
“The following are valid commands:”, 

u » 



“(c)heck hardware”, 

“(s)tart flight management unit”, 
“(q)uit flight management”, 
“(Dlight data menu”, 

“(m)emory contents display”, 
“(r)egister contents display”, 
“(i)nterrupt vector display”, 

“(d)os command”, 

“(t)erminate program”); 
break; 
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case ‘t’: 

printfT“\nTerminating Program...”); 
exit(O); 
default: 

puts(“\nNot a valid command. Type 7* for help.”); 
1 /* End Switch */ 

I /* End While */ 

) /* End Menu */ 



/* RTE, Page 4 */ 
/* QUIT */ 
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void initialize_hw( void ) 

|/* ******* ****** ************************************************** ******* 



This procedure initializes the PCL-812, PCL-744 and PCL-830 
hardware boards for UAV controller operation. 

*********************************************************************** j 



int rtn_code, port, i; 

int gpstart[]= {‘@’, : } ®\ y B\ 'a’, 0x01, 0x32, 0x0D,0x0A}; 

/* PCL-812 A/D Board Initialization **********************************/ 
/* Note: Jumpers on the PCL-812 must be jsetas follows: 

I/O Port Address (SW1): 220h, 0 Wait States 
Trigger Mode (JP1): Internal 
IRQ Level (JP4): 5 
A/D Input Range (JP9): +/- 5V 
Parameter Array as follows: */ 



dat = data; 
param[0] = 0; 
param[l] = 0x220; 
param[4] = 5; 
param[5] = 50; 
param[6] = 100; 
param[7] = 0; 
param[8] = 0; 
param[10] = FP_OFF(dat); 
paramUl] = FP_SEG(dat); 
param[12] = 0; 
param[13] = 0; 
paramll4j = 5; 
param[15] = 0; 
paramL16] = 5; 
param[17] = 0; 



/* Board number */ 
/* Base I/O address */ 
/* IRQ level : IRQ5 */ 
/* Pacer rate = 2M / (50 * 100) = 400 Hz */ 

/* Trigger mode: internal pacer trigger */ 
/* Non-cyclic mode */ 
/* Offset of A/D data buffer A */ 
/* Segment of A/D data buffer A */ 
/* Data buffer B offset: 0 if not used */ 
/* Data buffer B segment: 0 if not used */ 
/* A/D conversion number */ 
/* A/D conversion start channel */ 
/* A/D conversion stop channel */ 
/* Overall gain code, 0 : +/- 5V */ 



/* param[18] = FP_OFF(gain_array); FYI: Output Registers 
param[19] = FP_SEG(gain_array); 
param[45] : Error code 
param[46] : Return value 0 
param[47] : Return value 1 */ 



pcl812(3, param); /* Func 3 : Hardware initialization */ 

if (param[45] != 0) { 

printf(“\n PCL-812 Driver Initialization Failed!”); 
exit(l); 



pcl812(4, param); /* Func 4 : A/D initialization */ 

if (param[45] != 0) { 

printfl“\nA/D Initialization Failed!”); 
exit(l); 
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/*****:m:**************** PCL-744 Initialization ************************/ 
for (port = 3; port <= 10; port++) 1 /* Set up each port */ 

printfT“\nConfiguring port number %d (Cable #%d):”, port, port-2); 

/* Set I/Q co nt r ol params */ 
rtn_code = sio_ioctl( port, B9600, IOMODE ); 
if (rtn_code != 0) 

printfl“\nI/0 control error on port %d. y \ port); 

/* Set li n e control param et er s */ 
rtn_code = sio_lctrl( port, MODMODE ); 
if (rtn_code != 0) 

printfCXnLine control error on port %d”, port); 

/* Set flow control params */ 
rtn_code = sio_flowctrl( port, HWMODE ); 
if (rtn_code != 0) 

printfTXnFlow control error on port %d”, port); 

/* Last, open the port which enables it for I/O */ 
rtn_code = sio_open( port ); 
if (rtn_code != 0) 

printfT“\nError opening port %d”, port); 

1 /* End For port++ Loop */ 

/* Send T; tel l IMU to begin sending */ 
rtn_code=sio_putch( IMUPORT, T); 
if ( rtn_code == 1) printfC‘\n IMU initialized OK”); 
else printfCXn IMU NOT initialized”); 

/* Initialize GPS to send position msg every sec */ 
rtn_code=sio_putb( SGPS_PORT, gpstart, 8); 
if ( rtn_code <= 0 ) printfTXn GPS NOT initialized”); 
if ( rtn_code == 8 ) printfl“\n GPS initialized OK”); 

/* Set Tx/Rx timeout to 1 second */ 
rtn_code = sio_timeout( 18 ); 

/* Flush Rx an d Tx Bu ffe r s */ 
sio_flush( SGPS_PORT, 2 ); 
sio_flush( IMUPORT, 2 ); 
sio_flush( DLPORT, 2 ); 
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/*** PCL-830 Initialization (Am9513A chip) ************^^***************/ 
/* This portion of initializeO written by Pat Moran. */ 

/* All values are decimal, but represent binary register settings. */ 

/* See Am9513A Technical Manual for details */ 



outportb(conreg,255); 

outportb(conreg,23); 

outportb(datreg,176); 

outportb(datreg,65); 



outportb(conreg,249); 
for (i=l;i<=5;i++) 



/* Reset all board functions */ 
/* Select master mode register */ 
/* Low byte enables FOUT, FI source */ 
/* Hi byte selects binary division */ 
/* Disable increment, 8 bit bus */ 
/* FOUT on, divide by 1. */ 
/* RTE, Page 7 */ 

/* Diable prefetch for write ops */ 



outportb(conreg,i); /* Select ctrs 1-5 */ 

outportb(datreg,98); /* Low byte: set modes of ctrs 1-5 in CMR */ 

outportb(datreg,27); /* High byte: no gating for ctrs 1-5 */ 

} 

for (i=25;i<=29;i++) 



outportb(conreg,i); 
outportb(datreg,0); 
outportb(datreg,3 1); 



for (i=9;i<=13;i++) 



/* Load hold registers for refresh rate */ 
/* Load + Hold = Refresh Rate */ 
/* This combo gives 25 ms rate (40 Hz) */ 



outportb(conreg,i); /* Select load registers for pulse width */ 

outportb(datreg,103); /* Sets time for next pulse */ 

outportb(datreg,5); 

) 

for (i=233;i<=237;i++) outportb(conreg,i); 

outportb(conreg,i); /* Load & arm ctrs 1-5 */ 



outport(conreg,127); 

printfl“\nCompleted Initialization of Servos.”); 
I /* End Initialize_HW */ 
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void check_hardware(void) 

y * * * * * * * * if: * j|e * jjc * if: * * * * * * * * * * * * * j|c * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * :* *: * * * * * * * * * 

This procedure checks that all the hardware is properly 
configured and operational. 

*************************************************************************/ 



int i, card_type = 0x744, card_no = 1, rtn_code, port; 
char *buf = “Test String”; 
union REGS xreg, yreg; 

unsigned elist, drives=0, ports=0, printers=0; 

elist = biosequipO; /* Determine BIOS Equipment */ 

if (elist & 0x0001) drives = ((elist & OxOOcO) » 6)+l; 
ports = (elist & OxOeOO) » 9; 
printers = (elist & OxcOOO) » 14; 

printfT“\nThis system has %d diskette drives, %d serial ports, %d printer ports “,\ 
drives, ports, printers); 

if ((elist & 0x0002) » 1) printfTand a math co-processor.”); 

printfTXnlt has %uK of RAM and %lu stack available.”, \ 
biosmemoryO, coreleftO); 

rtn_code = sio_bank(card_type, card_no); /* Display address of PCL-744 card */ 
printfT“\nThe PCL-744 card is mapped to address %Fp”, rtn_code); 

rtn_code = sio_id( card_type, card_no); /* Display ID number of 744 card */ 
printfl“\nlt is card number %d”, rtn_code); 

for (port = 3; port <= 10; port++) { /* Set up each port */ 

printfT“\n\nChecking port number %d (Cable #%d):”, port, port-2); 

/* Check I/O Control Params */ 
rtn_code = sio_getbaud( port ); 

printf(“\nBaud rate of port %d set to %d”, port, rtn_code); 
rtn_code = sio_getmode( port ); 

printfI“\nMode of port %d set to %d.”, port, rtn_code); 

/* Ch eck Line C on tro l P a rams */ 
rtn_code = sio_lstatus( port); 
if (rtn_code < 0) 

printf(“\nError in status for port %d”, port); 

else 

printfI“\nModem line status of port %d is %d.”, port, rtn_code); 

/* Check Flow Control Params */ 
rtn_code = sio_getflow( port ); 

printfT“\nHardware flow control of port %d set to %d.”, port, rtn_code); 
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/* Do loopback test */ 
if (sio_loopback( port, buf, 12 ) == 0) 

printfl“\nPort %d loopback test OK.”, port); 

else 

printfT‘\nPort %d failed loopback test.”, port); 

printfl“\n\nReview data for port above. \nPress any key to continue.”); 
getchO; /* Wait for key */ 

) /* End For port++ Loop */ 

printff^XnXnParameter Array for PCL-830 board set to:”); 
for (i = 0; i <= 17; i++) { 

if (i== 10 I I i==ll) printfl a \nparam[%3d] = %Fp”, i, param[i]); 
else printR“\nparam[%3d] = %d”, i, param[i]); 

) 

( /* End Check_Hardware */ 
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void start_fmu(void) 

|/** ****** ******************************************************** ******** 

This procedure sets up the real-time clock to provide periodic 
interrupts at 64 Hz which will trigger the flight management unit. 

***************************************************************** ********/ 



unsigned char value, bit_set, new_value; 



if (fmu_start_flag == TRUE) ( /* Check if already started */ 

printfT“\nThe FMU has already been started.”); 
return; 

I 



printfT“\n\n Starting the Flight Management Unit.”); 

/* Get old vector number for posterity */ 
old_vector = getvect(RTCJNT); 

printfTXnThe address of the old vector is: %Fp\n”, old_vector); 

/* Now set RTC to generate interrrupt at rate set in DEFS.h */ 

/* Alter interrupt rate to new rate (32768 » RATE_SET - 1) */ 
value = ReadRTC(REG_A); /* Read register A */ 

bit_set = value & OxFO I RATE_SET; /* Lowest 4 bits sets rate of int */ 
SetRTC(REG_A, bit_set); /* Set to new rate of periodic int */ 

new_value = ReadRTC(REG_A); 

printfT“\nReg A was %x, now %x with new rate set.”,value, new_value); 

/* Enable pe riodic inte rrupts with the RTC */ 
disableO; 

value = ReadRTC(REG_B); /* Read register B */ 

bit_set = value I INT_FLAG; /* Enable periodic interrupts */ 

SetRTC(REG_B, bit.set); /* on IRQ 8 (Int 70). */ 

new_value = ReadRTC(REG_B); 

printfT u \nReg B was %x, now %x with int flag set.”, value, new_value); 

/* Change interrupt vector to run mv program */ 

disableO; /* Disable interrupts when changing */ 

setvect(RTC_INT, new_vector); 

enableO; 

printfT“\nInstalled new vector: %p\n”, new_vector); 

value = ReadRTC(REG_C); /* Clear pending int by reading reg */ 
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/* Initialize PIC to enable interrupts */ 

value = inportb(PIC_STATUS); /* Read PIC Status Register */ 

bit_set = value & Oxfe; 

outportb(PIC_STATUS, bit_set); /* Clear bit 0 to enable ints */ 

new_value = inportb(PIC_STATUS); 

printfTXnPIC mask was %x, now %x with bit 0 cleared.”, value, new_value); 
enableO; 

fmu_start_flag = TRUE; 

I /* End Start.FMU */ 
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void quit_fmu(void) 

This procedure stops the periodic interrupt, effectively halting the 
flight management unit, and resets the real-time clock chip back to 
its original configuration. 

*%******%%%***%%%*****%%*%%%*%%%********%%***%*%:*%***********************/ 
unsigned char value, bit_set, new_value; 

if (fmu_start_flag == FALSE) ( /* Make sure it has been started */ 

printfT“\nThe fmu has not yet been started.”); 
return; 

I 

else { 

printfl“\n\n Stopping the Flight Management Unit.”); 

/* F ut system b ack u> no rm a l */ 

/* First clean up RTC */ 

disableO; /* Disable interrupts while changing */ 

/* Clear periodic interrupt bit */ 
value = ReadRTC(REG_B); 
bit_set = value & OxBF; 

SetRTC(REG_B, bit_set); 

new_value = ReadRTC(REG_B); 

printfI“\nReg B was %x, now %x with int flag clrd.”, value, new_value); 

/* Beset rate tQ.10Zi.Uz */ 
value = ReadRTC(REG_A); 
bit_set = value & OxFO I 0x06; 

SetRTC(REG_A, bit_set); 

new_value = ReadRTC(REG_A); 

printfT“\nReg A was %x, now %x with new rate set.”, value, new_value); 

/* Reset in terrup t ve ctor to or i gi n al, value */ 

setvect(RTC_INT, old_vector); 

enableO; 

printfI“\nThe cyclecount is: %d\n”, cyclecount); 

fmu_start_flag = FALSE; 

(/* End Else */ 

) /* End Quit_FMU */ 
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unsigned char ReadRTC( unsigned char reg ) 

| j*. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * a|c * * * * * * * * 

This function returns the value of the specified register on the 
real-time clock chip. 

sf:^:****^:^:*^:****************^^^:***^:^:*^:*^^^:^:^:^*^:^:^:^^***** ************ *******/ 

unsigned char reg_nmi, value; 



reg_nmi = reg I NMI_FLAG; /* Disable Non-Maskable Int */ 

outportb (RTC_INDEX, reg_nmi); /* Tell CMOS which reg to read */ 

value = inportb (RTC_DATA); /* Read value of register */ 

return value; 

} /* End Read_RTC */ 



void SetRTC( unsigned char reg, unsigned char value ) 



This procedure sets a new value into the specified register 
of the real-time clock chip. 



unsigned char reg_nmi; 



reg_nmi - reg I NMI_FLAG; 
outportb (RTC_INDEX, reg__nmi); 
outportb (RTC_DATA, value); 

I /* End Set RTC */ 



/* Disable Non-maskable Int */ 
/* Tell CMOS which reg to set */ 
/* Write value to register */ 



void interrupt new_vector() 

j^jfcjfc****** *** ********* * ***:+: * *********** *****:+: ****** ************ *********** 

This is the flight management unit procedure that is run on each 
occurrence of the periodic interrupt. 

*** 4c****************************** ********************** ******* ********* *yf 



cyclecount++; /* Count number of cycles */ 

cyclecount %= RATE*10; /* Normalize count every 10 seconds */ 

resetJntO; /* Reset Interrupt to enable next one */ 

execute_cycle(); /* Do something constructive */ 

) /* End New__Vector */ 



void reset_int(void) 

|/*** ************************************************************** ******* 
This procedure resets the real-time clock chip and the PIC chips 
in order to facilitate another periodic interrupt. 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */ 
unsigned char value; 

value = ReadRTC(REG_C); /* Must read reg C to get another int */ 

disableO; 

outportb(0x0a0, 0x20); /* Send non-specific EOI to slave PIC */ 

outportb(0x20, 0x20); /* and master PIC */ 

enable!); 

I /* End Reset_Int */ 
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void execute_cycle(void) 

This procedure is the heart of the controller. It is the routine 
that is invoked during every occurrence of the real-time clock 
interrupt, coordinating the execution of other modules which 
comprise the control and communication processes of the UAV. 

unsigned char value, bit_set; 
int imu_ok, gps_ok, dl_ok; 

value = inportb (0x61); 

bit_set = value A 0x02; /* Toggle speaker enable bit */ 

outportb(0x61, bit_set); /* (Sounds like the motor is running) */ 



/* sio_putb( DLPORT, “GPS: 5); 

Slave _gps( gps ); Calls to Eric Twite’s Stuff 

xmit_to_gnd( &gps->out ); (Not yet operational) 

free( gps->out.ptr ); *****/ 



dl_ok = read_datalink( dl_buf ); /* Read uplink every cycle */ 

/* Put code to deal with info from datalink uplink here */ 



if (cyclecount % 4 == 0) { /* Read IMU every 4th cycle */ 

imu_ok = read_imu( imujbuf ); /* Send every 0.5 sec */ 

if ( cyclecount % (RATE/2) == 0 && imu_ok ) { 

sio_putb( DLPORT, “IMU: “, 5); /* IMU label in data stream */ 

xmit_to_gnd( imu_buf ); 



ifl cyclecount % (42) == 0) { 

gps_ok = read _gps( gps_buf ); 
if (gps_ok) ( 

sio_putb( DLPORT, “GPS: “, 5); 
xmit_to _gnd( gps_buf ); 



/* Read GPS every 1.3 sec */ 

/* If full msg rcvd, */ 

/* also send to ground */ 
/* with data stream label */ 



read_atod(); 



/* Read AtoD every cycle */ 



/* Last, with all flight data in hand, control aircraft */ 
flight_control( &thr_cmd, &ail_cmd, &elev_cmd, &rud_cmd); 
cmd_to_servos( thr_cmd, ail_cmd, elev_cmd, rud_cmd); 



) /* End Execute_Cycle */ 
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int read_imu( PANDL *buffer ) 

|yf** ******************************************************** ************** 

This procedure reads into a pre-established buffer the data 
from the onboard Inertial Measurement Unit. 

*************************************************♦***********************/ 



int eol = CR; 
int queue; 



queue = sio_iqueue( IMUPORT ); 

if (queue > 100) queue = 100; /* Truncate to size allocated in main */ 

if (queue > 38) { /* Buffer has at least 1 full + partial msg */ 

buffer->len = sioJinput( IMUPORT, buffer->ptr, queue, eol ); 
buffer->len = sio_read( IMUPORT, buffer->ptr, 38); 



else if (queue > 0) /* or has at most 1 full msg (usual condition) */ 

buffer->len = sio_linput( IMUPORT, buffer->ptr, queue, eol); 

else 

buffer->len = 0; /* or has nothing in the buffer */ 

if (buffer->len == 38) return TRUE; /* Test if message is complete*/ 

else return FALSE; 

I /* End ReadJMU */ 



int read_gps( PANDL *buffer ) 

^*********** ************************************ ************************* 
This procedure reads into a pre-established buffer the data 
from the onboard Global Positioning System. 
*********************************************************************** **/ 
int eol = LF, queue; 



queue = sio_iqueue( SGPS_PORT ); /* How long is rev queue? */ 

while (queue > 135) ( /* Pare down to last 2*68-1 chars */ 

queue -= 135; /* (At most 1 full message) */ 

if (queue < 68) queue += 68; /* (But at least 1 full message) */ 

if (queue > 500) /* Max buffer space 500 bytes */ 

buffer->len = sio_read( SGPS_PORT, buffer->ptr, 500); 

else 

buffer->len = sio_read( SGPS_PORT, buffer->ptr, queue); 
queue = sio_iqueue( SGPS_PORT ); 



/* Now, at most 1 full msg exists in the queue ± mavbe a partial msg */ 
if (queue > 68) /* If partial msg exists, read it away */ 

buffer->len = sio_linput( SGPS_PORT, buffer->ptr, queue, eol ); 

/* Now, only 1 full msg should exist in the Queue, so read it */ 
buffer->len = sio_linput( SGPS__PORT, buffer->ptr, queue, eol ); 

if (buffer->len == 68) return TRUE; /* Test to make sure full msg */ 

else return FALSE; 

I /* End Read_GPS */ 
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void read_atod(void) 

This procedure calls PCL-812 intrinsic function 5, which triggers an 
A/D conversion on analog data inputs as set in the param array. 
*************************************************************************/ 
/* Record A/P Co n vers ions */ 

pcl812(5, param); /* Func 5 : Pacer trigger A/D conversion */ 

if (param[45] != 0) /* with software data transfer */ 

printfT‘\nA/D Conversion Failed!”); 

) /* End Read_AtoD */ 



void xmit_to_gnd( PANDL *buffer) 

y************************************************************************ 



This procedure transmits the contents of the buffer to the ground 
through the datalink. 

********************** ************** *************************************/ 



int strglen, txbuff; 



if (buffer->len > 0) I 

txbuff = sio_ofree( DLPORT ); /* Get free space in xmit buffer */ 

if (buffer->len < txbuff) ( /* If enough buffer space, send */ 

strglen = sio_putb(DLPORT, buffer->ptr, buffer->len); 
if (strglen == 0) { /* Else */ 

sio_flush(DLPORT, 1); /* Get rid of the old data */ 

strglen = sio_write(DLPORT, 'WARNING: Buffer cleared! 25); 
strglen = sio_write(DLPORT, buffer->ptr, buffer->len); 



I /* End Xmit_to_Gnd */ 



int read_datalink( PANDL ^buffer ) 

I/************************************************************************ 

This procedure reads the contents of the datalink's receive buffer 
containing information sent from the ground through the datalink. 

int queue, eol = '#’; 

queue = sio_linput(DLPORT, buffer->ptr, 100, eol); /* Get queue length */ 
if (queue > 0) ( /* If something is in queue, read it */ 

queue = sio_read(DLPORT, buffer->ptr, 2); /* Read length of msg */ 

buffer->len = atoi(buffer->ptr); /* Convert length to an integer */ 

/* Read in buffer of specified length */ 

queue = sio_read(DLPORT, buffer->ptr, buffer->len); 

return TRUE; 

) 

else return FALSE; /* If nothing waiting in buffer, continue */ 

) /* End Read_Datalink */ 
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void flight_control(int *thr, int *ail, int *elev, int *rud) 

This procedure is a place holder for the actual control algorithm 
being designed by the Aeronautical Engineering Department. 



The procedure envisioned here will perform appropriate data filtering 
and will use the filtered data to calculate the necessary control 
surface positions. The output of this procedure is the angle of each 
of the standard control surfaces. The cmd_to_servos procedure will 
convert these standard control surfaces into individual control vane 
angles. This conversion will differ depending on the mode of flight, 
whether vertical or horizontal. 



/* Get or calculate pilot commands */ 
/* Calculate control surface inputs */ 



/* The steps below are just a demo to exercise the servos to their 
full extension in increments of 2 degrees until replaced by the 
actual control algorithm */ 



*thr = 100; /* Throttle stays constant */ 

vane_step += 2; /* Increase vanes 2 deg each cycle */ 

vane_step %= 200; /* All vanes go -30 to +30 deg */ 

*ail = vane_step; 

*elev = vane_step; 

*rud = vane_step; 

/* Delete global va riable step, v ane w hen this test, routine deleted */ 

) /* End Flight.Control */ 
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void cmd_to_servos(thr, ail, elev, rud) 

3|c2(c3fc3fca|c2fc3|c3|caf;3|c3fc3fcafc3fc ****************************************************** ***/ 

/* Written by LCDR Pat Moran 5/14/93 */ 

/* Originally called chgangleO - see thesis description */ 

/* Basic PWM routine by LT Paul Merz [Mer92] */ 

/* Demo to move aileron, rudder, elevator, & throttle from 2 joysticks. */ 

/* Blends 3 degrees-of-freedom into 4 independent vane commands. */ 

/********************** *********************************************** ****/ 



int i,hibyte,lobyte, angle, vane[51; 

vane[0J = ail/4 + rud/2; 
vane[l] = ail/4 + elev/2; 
vane[2] = ail/4 - rud/2; 
vane[3] = ail/4 - elev/2; 
vane[41 = thr; 
outportb(conreg,223); 



/*V1; Translation algorithm fm 3 */ 
/* V2; control surfaces to 4 vanes */ 
/* V3; */ 

/* V4; */ 

/* Throttle needs no conversion */ 
/* Disarm counters 1-5 */ 



for (i=0;i<=4;i++) ( 

angle=((1900/206)*(vaneti])+600); 

hibyte=(angle/256); 

lobyte=(angle-hibyte*256); 

outportb(conreg,(i+9)); 

outportb(datreg,lobyte); 

outportb(datreg,hibyte); 

) 



/* Convert fm deg to dig # */ 
/* Calc high byte, residue left */ 
/* Calc low byte fm residue */ 
/* Load counters 1-5 */ 
/* Load low byte */ 
/* Load high byte */ 



for (i=233;i<=237;i++) 

outportb(conreg,i); /* Set toggle high for counters 1-5 */ 

outportb(conreg,127); /* Load & arm counters 1-5 */ 

I /* End Cmd_to_Servos */ 
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void show_flight_data(void) 

This procedure queries the user to determine which flight data to 
display and calls the appropriate routine. 

char ch; 



printfT“\n%s\n%s\n%s\n%s\n%s\n%s\n\n%s”, 
“Display which data?”, 



y 

“(g)ps position”, /* Can list other gps data here too */ 

“(i)mu data”, 

“(a)ir data”, 

“(s)ervo positions”, 

“Choice: “); 
scanfl“%s”, &ch); 
switch (ch) ( 

case ‘g: /* GPS Position */ 

show _gps_posit(); 
break; 



case T: 

show_imu(); 
break; 
case 'a’: 

sh o w_air_d ata( ) ; 
break; 
case 's': 

show_servo_posit(); 

break; 

default: 

printfl“\nData choice not recognized!”); 
return; 

) /* End Switch */ 



/* IMU Data */ 



/* Analog Air Data */ 



/* Servo Position */ 



1 /* End Show_Flight_Data */ 



void show_imu(void) 

| !%. 2 fc sfc sfc sfc 9{c sfc 2 fc Sfc 3fC 3fC sfc 3fC 3fC 3fC 3fC 3fC 3fC 3fC 3|C 3fC 3)C 3fC 3fC 3fC 3fC 3fC 3|c 3fC 3{C 3fC 3fC 3fC 3fC 3fC 3|C 3|C 3fC 3fC 3fC 3fC 3fC 3fC 

This procedure prints the most recently acquired IMU data, 
int i; 

printfI“\nLatest IMU data: %d characters. \n”, imu_buf->len); 
for (i = 0; i < imu_buf->len; i++) { 
putchar(imu_buf->ptr[i]); 
if (i % 4 == 0) putcharO *); 

) 

I /* End ShowJMU */ 
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void show_gps_posit(void) 

jy* ********************************************************** ************* 

This procedure prints the most recently acquired GPS data. 

****** * ** * * * * ******* **************************************************** *y 

int i; 

/* To print from Twite’s GPS structure, when complete */ 

/* printfl“\n Latest GPS positionAnLat: %d.%d N, Long: %d.%d W”,\ 
gps->pcs.latitude. degrees, gps->pcs.latitude. minutes, \ 
gps->pcs.longitude. degrees, gps->pcs.longitude. minutes); 

*/ 

/* To print from gps buf raw data buffer */ 

gps_print =s Bin_to_ascii( gps_buf, 4); /* Convert to ASCII chars */ 

printfTAnLatest GPS data: %d / %d characters. \n”, \ 
gps_buf->len, gps_print->len); 

for (i = 0; i < gps_print->len; i++) putchar(gps_print->ptr[i]); 

free(gps_print->ptr); 

free(gps_print); 

) /* End Show_GPS_Posit */ 



void show_air_data(void) 

jy* ************************************* ********************************** 

This procedure prints the most recently acquired A/D data. 

************************************************************ *************y 



unsigned int i; 
float DataBuf; 



/* Calculate an a log Ya .lu.es from raw data in data array */ 
for (i = 0; i < param[16J; i++) I 
DataBuf = data[i] & OxFFF; 

DataBuf = (10 * DataBuf / 4096) + (-5); 

/* Calculations: 

10 : A/D input range (-5V to 5V) 

4096 : Full scale 12 bit A/D data 

DataBuf : A/D input data masked to 12 bits 
(-5) : A/D input base “-5” V 

*/ 

printfT“\ndata[%3d] = % 1.2f V returned as %x”, i, DataBuf, data[i]); 
1 /* End For all data entries */ 

1 /* End Show_Air_Data */ 



void show_servo_posit(void) 

jy**** *********************************************************** ********* 

This procedure prints the present position of all servos. 

****************** *******************************************************y 

printft“\nThr: %d, Ail: %d, Elev: %d, Rud: %d.”, \ 
thr_cmd, ail_cmd, elev_cmd, rud_cmd); 

I /* End Show_Servo_Posit */ 
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void close_ports (void) 

|y* ********************************** ************************************* 

This procedure closes all serial ports on the PCL-744 card and 
flushes transmit and receive buffers for each port. 

************************************************************** ***********y 

int port, rtn_code; 

for (port = 3; port <= 10; port++) ( 
rtn_code = sio_close( port ); 
if (rtn_code != 0) 

printfl“\nError closing port %d’\ port); 

else 

printfT“\nClosed port %d”, port); 
sio_flush( port, 2); 

) /* End For all ports */ 

I /* End Close_Ports */ 



void shut_down(void) 



|/* ************* ******* 



***************** ****** ************ ***** *********** 



This procedure is invoked at program exit to ensure that the system, 
including communication ports, ISR vectors, and allocated memory, is 
properly terminated and returned to its normal operating configuration. 

******************************************************************** *****y 

quit_fmu(); /* Stop the flight management unit */ 

close_ports(); /* Close and flush all ports */ 

free(gps); /* Free all globally allocated memory */ 

free(imu_buf->ptr); 

free(imu_buf); 

free(gps_buf->ptr); 

free(gps_buf); 

free(dl_buf->ptr); 

free(dljbuf); 

} /* End Shut_Down */ 
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void int_vector(void) 

|/*********** *************** ************ *********** ***************** * ** 

This procedure prints the address registered for the ISR of the 
interrupt number given by the user. 

****************************************************************** *******y 

void interrupt (*int_handler)(); 
int intno; 

printfl“\nEnter interrupt number in hex: “); 
scanfl“%x”, &intno); 
int_handler = getvect(intno); 

printfTXnThe address of the handler is: %Fp\n”, int_handler); 

) /* End Int_Vector */ 



void mem_dump(void) 

|y** ******************************************************* *************** 

This procedure prints the values of a given portion of memory. 
*************************************************************************/ 
int i, n; 

char far *far_ptr; 

printfI“\n\nEnter begin memory address to dump (eg. F000:E000): “); 

scanfT“ %p”, &far_ptr); 

printfT“\nHow many bytes to display? “); 

scanfT“%d”, &n); 

printfT‘\nDump of %d bytes at %Fp\r\n”, n, far_ptr); 
for(i=0; i<n; i++) { 

printfl“\n%Fp %Fx”, (far_ptr+i), *(far_ptr+i)); 

1 

I /* End Mem_Dump */ 



void show_regs(void) 

|y******* ******************************************************* ********** 

This procedure prints the current values of all CPU and segment 
registers. 

******************************************************************* ******y 

union REGS xr, yr; 
struct SREGS sr; 

segread(&sr); 

printfTXnax = %x, bx = %x, cx = %x, dx = %x”, \ 
xr.x.ax, xr.x.bx, xr.x.cx, xr.x.dx); 
printfT“\nsi = %x, di = %x, cflag = %x, flags = \ 

xr.x.si, xr.x.di, xr.x. cflag); 
bit_print(xr.x.flags); 

printfl“\ncs = %x, ds = %x, es = %x, ss = %x”, \ 
sr.cs, sr.ds, sr.es, sr.ss); 

1 /* End Show_Regs */ 
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void bit_print(unsigned int v) 

|y** *********************** ******** 



*************************************** 



This procedure prints the binary representation of the given 
hexidecimal number. 

**************************************************************** *********y 



int i, mask = 1 « 15; 



printfr%x = ", v); 
for (i = 1; i <= 16; i++) { 

putchar(((v & mask) == 0) ? ‘O’ : T); 
v <<= 1; 

if (i % 4 == 0) putchar(‘ ‘); 

} 

) /* End Bit_Print */ 



void dos_cmd(void) 

1 ^* ************ ********* 



************************************************** 



This procedure invokes a DOS shell. 



char cmd[40J; 



printfTXnDOS COMMAND:> “); 

gets(cmd); 

system(cmd); 

) /* End DOS_Cmd */ 



88 



/* RTE, Page 24 */ 



int break_handler(void) 

I/*********** afeafcafcafcafcafcaleafcafca^afcafe afcafcafcafcafcafcafcafcafcafcafcafcatcaicatcafcatcafcatcafc ***********************:****** 

This procedure is invoked upon a control-break or control-c sequence 
from the keyboard. It gives the user more flexibility in determining 
how extensively he desires to reset the system. 

^j^*****#:**** ************************************************************ */ 

char ch; 

union REGS xreg, yreg; 

printfT“\n%s\n%s\n%s\n%s\n%s\n%s\n%s\n%s”, 

‘Why did you break?”, 

u » 

- , 

“(c)old reboot machine”, 

“(w)arm reboot machine”, 

“(r)estart program (reinitialize hardware)”, 

“(g)o back to main menu”, 

“(t)erminate program”, 

“Choice: “); 
scanfl“%s”, &ch); 
switch (ch) { 

case ‘c’: /* Cold Reboot */ 

bootstrap(O); 
break; 

case V: /* Warm Reboot */ 

bootstrap(l); 
break; 

case V: /* Restart Program */ 

shut_down(); 
longjmp(cbreak_rtn, 1); 
break; 

case ‘g’: /* Main Menu */ 

menuO; 
break; 

case ‘t’: /* QUIT */ 

printfT“\nTerminating Program...”); 
exit(O); 
default: 
menuO; 

} /* End Switch */ 

( /* End Break_Handler */ 
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void bootstrap(int input) 

I 

union REGS reg; 
void (far *reboot)(void); 
int far *boottype; 

/* Set Far Pointers to the Boot Sector */ 

FP_SEG( reboot) = Oxffif; 

FP_OFF(reboot) = 0; 

FPjSEG(boottype) = 0x40; 

FP_OFF(boottype) = 0x72; 

/* Issue a DOS disk reset request to flush caches */ 
reg.h.ah = OxOd; 
int86(0x21, &reg, &reg); 

/* Set boot type and execute reboot */ 

*boottype = (input ? 0x1234 : 0); /* 0 = Cold, 1 = Warm */ 

(*reboot)(); 

) /* End Bootstrap */ 

/* End of Real-Time Executive Program */ 
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APPENDIX B: LIST OF VARIABLES 



The following is a reference listing of the definitions of all variables used in the Real-Time Executive source 
code shown in Appendix A. (G) indicates a globally maintained variable. 



angle 

bit_set 

♦boottype 

buffer->len 

buffer->ptr 

cbreakrtn 

ch 

cyclecount 

*dat 

data[20] 

DataBuf 

d!_buf 

dlok 

eol 

*far_ptr 

fmu_start_flag 

gps_buf 

gpsstart 

gps_ok 

hibyte 

i 

imujbuf 

imu_ok 

intno 

lobyte 

*old_vector 

new_value 

param[60] 

port 

queue 

♦reboot 

reg_nmi 

rtn_code 

sr, xr, yr 

strglen 

txbuff 

value 

vane 

vanestep 



Value of digital representation of servo command angle 

Bit value to be written to register from the Real-Time Clock (RTC) chip 

Pointer to memory location specifying hard or cold boot 

Lenght field of PANDL structure. Represents the length of the buffer. 

Pointer field of PANDL structure. Points to the actual data buffer. 

Pointer to position in program to return to after control-break (G) 

Variable to hold user response to menu selection 
A counter incremented on every cycle of a control loop (G) 

The pointer to the data array (G) 

An array in which the PCL-812 stores the results of its A/D conversions (G) 
Value of actual voltage calculated from A/D conversion data 
PANDL to store raw data received through the datalink (G) 

Boolean set true if message received on datalink 
Character which ends complete message from IMU or GPS 
Pointer to memory location to begin inspection 
Boolean variable toggled on when FMU is started (G) 

PANDL to receive raw data retrieved from GPS receiver (G) 

Array to hold sum sequence to be sent to GPS receiver 
Boolean set true if GPS message received is complete 
Value of high byte given to PCL-830 for the PWM signal 
Loop increment used in various places 
PANDL to receive raw data retrieved from IMU (G) 

Boolean set true if IMU message received is complete 
Number of interrupt for which requesting ISR vector address 
Value of low byte given to PCL-830 for the PWM signal 
Pointer to hold value of old interrupt ISR vector (G) 

Value of register read from RTC after a modification 

An array of parameters used to configure the PCL-812 board (G) 

For loop increment to configure all ports 
Length of receive queue buffer from IMU or GPS 
Pointer to memory location to jump to causing reboot 

Value of register read from the RTC with Non-Maskable Interrupt (NMI) bit set 

Code returned from execution of PCL-744 I/O program 

Values read from computer internal registers 

Number of characters transmitted to datalink buffer 

Length of free space available in datalink transmit buffer 

Value of register read from the RTC 

Array holding vane servo commands for each of the servos 

Temporary variable holding command for control vane position (G) 
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Introduction 

We designed the PCA-6146 for users 
who require high speed system 
performance in their industrial PC 
applications. The card is available in five 
80486 CPU versions: 80486SX-25, 
80486SX-33, 80486DX-33, 80486DX2- 
50 or 80486DX2-66. The card's all-in- 
one design includes memory caching, 
disk drive controllers, a watchdog timer 
and serial/parallel ports. We give every 
card a 24-hour dynamic burn-in test to 
ensure component reliability in harsh 
environments at temperatures up to 
140°F (60°C). 

With the PCA-6146 plugged into your 
passive backplane, your industrial PC 
becomes a true 32-bit 80486 
compatible computer system. 

The card’s highly compact size, 
numerous features and unmatched cost/ 
performance ratio make it ideal for 
high-end industrial applications where 
high CPU speed, minimum space and 
short MTTR are crucial. 



Each PCA-6146 ships with either an 
80486DX-33 MHz, 80486DX2-50 MHz 
or an 80486DX2-66 MHz CPU. These 
state-of-the-art CPUs feature an on-chip 
math coprocessor and an 8 KB cache 
memory for floating point calculations 
and fast memory access. 256 KB of 
2nd-level cache memory allows the card 
to run at Landmark speeds in excess of 
150 MHz. 

Other standard features include two 
RS-232 serial ports, one parallel/printer 
port, an IDE hard disk drive interface, a 
floppy disk controller, a watchdog 
timer, piggyback module connectors 
and an on-board keyboard connector. 
You can configure system memory to 
anywhere from 1 MB to 16 MB using 
256 KB, 1 MB or 4 MB SIMM DRAM in 
the PCA-6146’s four memory sockets. 



Features 

• Completely 80486 PC/AT compatible 

• 32 to 140°F (0 to 60°C) operating 
temperature 

• Watchdog timer 

• Optional Flash/RAM/ROM Disk 
Piggyback Module (PCD-8931) and/or 
Flat-panel/CRT VGA Piggyback 
Module (PCA-6443) install on the 
piggyback connector 

• 80486 processor and AMI BIOS 

• ETEQ’s Cougar chipset 

• 256 KB 2nd-level cache memory 

• Up to 16 MB of on-board DRAM 

• Built-in IDE (AT bus) hard disk drive 
interface 

• Built-in floppy disk drive controller 

• Two serial RS-232 ports 

• One parallel/printer port 

• On-board keyboard connector 

• Lithium battery back-up for real-time 
clock/calendar 
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Spetifhations 

• CPU: 80486SX/DX/DX2-25/33/40/50/66 MHz 

• Cache memory size: 8 KB on-chip and 256 KB 2nd level 

• Bus interlace: ISA (PC/AT) bus 

• Data bus: 32 bit 

• Processing ability: 32 bit 

• Coprocessor: Socket for Weitek 4167 

• RAM memory: 1 MB to 64 MB, uses four banks of SIMM 
sockets composed of eight 30 pin sockets and two 72-pin 
sockets (72-pin sockets accept 1, 2, 4, 8 and 16 MB 
SIMMs) 

• Shadow RAM memory: Supports system and video BIOS of 
up to 256 KB in 32 KB blocks 

• IDE hard disk drive interface: Supports up to two IDE (AT 
bus) hard disk drives. BIOS enabled/disabled 

• Floppy disk drive interface: Supports up to two floppy disk 
drives, 5.25' (360 KB and 1.2 MB) and/or 3.5‘ (720 KB and 
1.44 MB). BIOS enabled/disabled 

• Bi-directional parallel port: Configurable to LPT1, LPT2, 
LPT3 or disabled. Standard DB-25 female connector 
provided 

• Serial ports: Two RS-232 serial ports can be individually 
set to COM1 , COM2 or disabled. Each can be accessed 
through a DB-9 male connector 

• Real time clock/calendar: Dallas DS-1287 with lithium 
battery back-up for 10 years of data retention 

• Watchdog timer: Jumper configurable to, always disabled 
or software enabled/disabled. The timer interval is 1.6 sec. 
Your program uses I/O ports hex 043 and 443 to control the 
watchdog timer and generate a system reset or IRQ15 

• Piggyback connector: 16-bit bus connector (64 + 36 pins) 
for expansion modules 

• DMA channels: 7 

• Interrupt levels: 15 

• Keyboard connector: A 6-pin mini DIN keyboard connector 
is located on the mounting bracket for easy access. An 
external keyboard adapter is included. An on-board 
keyboard pin header connector is also available 

• Bus speed: 8 MHz 

• System performance (w/ 80486DX-50 MHz CPU): 200 MHz. 
Landmark speed VI .14; 167 MHz, Landmark speed V2.0 

• Max. power requiremenls: +5 V @ 2.5 A 

• Power supply voltage: 

+5 V (4.75 V to 5.25 V), +12 V, -12 V 

• Operating temperature: 32 to 140°F (0 to 60°C) 

• Board size: 13.1" (L) x 4.8' (W) (334 mm x 122 mm) 

• Board weight: 1 .2 lbs (0.5 Kg) 



Ordering Information 

□ PCA-6147-33/Bare: All-in-one 80486 CPU Card without 
CPU. Includes 256 KB cache memory, users manual, IDE 
hard disk cable, floppy drive cable and parallel port adapter 

□ PCA-6147SX-25/0K: Same as above but with 25 MHz 
80486SX CPU installed 

□ PCA-6147SX-33/0K: Same as above but with 33 MHz 
80486SX CPU installed 

□ PCA-6147DX-33/0K: Same as above but with 33 MHz 
80486DX CPU installed 

□ PCA-6147DX-50/0K: Same as above but with 50 MHz 
80486DX CPU installed 

□ PCA-6147DX2-50/0K: Same as above but with 50 MHz 
80486DX2 CPU installed 

□ PCA-6147DX2 -66/OK: Same as above but with 66 MHz 
80486DX2 CPU installed 



On-board POST diagnostit LEDs 
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Specifications 

CPU: 80486SX/DX/DX2-25/33/50/66 MHz 

Cache memory size: 256 KB 
Bus interface: ISA (PC/AT) bus 
Dat£ bus: 32 bit 
Processing ability: 32 bit 
Chipset: ETEQ’s Cougar chipset 

RAM memory: 1 MB, 4 MB and 16 MB. Uses 256Kx9 
(SIMM-256-8), 1Mx9 (SIMM-1000-8) or4Mx9 (SIMM- 
4000-8) SIMMs with access time of 80 ns or less 

CPU Comparison: 



CPU 


1 804B5DX-33 


\ 804SSDX2-50 


i S043SDX2-SS 


Co-processor 

I 


Boat-in 






! Cache meipory 


8K3 + 25$ KB 


!$ KB -256 KB' 


1 3 KB <*> 256 KB 


Landmark 
Speed 1.14 


| 150.2 MHz 


17C.1 MHz 


1 >2C0 MHz 


System Clock 


33 MHz 


25 MHz 


33 MHz 



Shadow RAM memory: Supports up to 256 KB of memory 
in 16 KB blocks for system and video BIOS 

Hard disk drive interface: Supports up to two IDE (AT-Bus) 
hard disk drives. Jumper enabled/disabled 

Floppy disk drive interface: Supports up to two floppy disk 
drives: 5V* (360 KB and 1.2 MB) and/or 3 W (720 KB and 
1.44 MB). Jumper enabled/disabled 

Parallel/printer port: 

Configurable to LPT1, LPT2, LPT3 or disabled. A standard 
female DB-25 connector is provided 

Serial ports: Two RS-232 serial ports individually 
configurable to COM1, COM2 or disabled. Each port is 
accessed through its own male DB-9 connector 

Real time clock/calendar: 

Real time clock/calendar with lithium battery back-up 
(3.6 V @ 850 mAH). External battery connector provided 

Watchdog timer: Jumper configurable to always ON, always 
OFF, or programmable ON/OFF. The time-out interval is 
jumper selectable to 1.5, 15 or 150 seconds 

Piggyback connector: 64-pin, 8-bit bus connector with 
a low-line detector and battery back-up reserved for option 
modules such^s Flash/RAM/ROM disk module and/or Flat- 
panel/CRT VGA'modules 

DMA channels: 7 



• Interrupt levels: 15 

• Keyboard connectors: A 6-pin mini-DIN keyboard connector 
is located on the mounting bracket for easy access. An 
external keyboard adapter is included. An on-board 
keyboard pin header connector is also available 

• Bus speed: 8 MHz. 

• System performance: 150 MHz with an 80486DX-33 MHz 
(Landmark speed VI. 14). 

• Max. power requirements: +5 V @ 2.5 A 

• Operating temperature: 32 to 140°F (0 to 60°C) 

• Board size: 13. 1* (L) x 4.8‘ (W) (334 mm x 122 mm) 

• Board weight: 1.5 lbs (0.7 Kg) 

• EMI: meets FCC class A and BZT Class A 

• MTBF: 87,100 hrs @ 25°C; 31,900 hrs @ 60°C 



Ordering Information 

□ PCA-61 46-33/Bare: 

All-in-one 80486 CPU Card without CPU. Includes 256 KB 
memory, user’s manual, IDE hard disk drive cable, floppy 
disk drive cable, parallel port adapter and keyboard 
adapter. 

□ PCA-61 46SX-25/0K: 

All-in-One 80486SX-25 CPU Card with 256 KB cache 
memory and all accessories of the PCA-6146-33/Bare 

□ PCA-6146SX-33/0K: 

All-in-One 80486SX-33 CPU Card with 256 KB cache 
memory and all accessories of the PCA-6146-33/Bare 

□ PCA-6146DX-33/0K: 

All-in-One 80486DX-33 CPU Card with 256 KB cache 
memory and all accessories of the PCA-6146-33/Bare 

□ PCA-6146DX2-50/0K: 

All-in-one 80486DX2-50 CPU Card with 256 KB cache 
memory and all accessories of the PCA-61 46-33/Bare 

□ PCA-61 46DX2-66/0K: 

All-in-one 80486DX2-66 CPU Card with 256 KB cache 
memory and all accessories of the PCA-61 46-33/Bare 
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